From leonard at den.ottolander.nl Fri Oct 1 14:27:12 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 01 Oct 2004 16:27:12 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <415C47F2.9010102@gmx.de> References: <415C47F2.9010102@gmx.de> Message-ID: <1096640832.4778.5.camel@athlon.localdomain> Hello Roland, > this patch fixes the second TODO item for 4.6.1. It is not perfect, but > it works. We should do much more error checking at this point, for > example for "../file" or similar things. Therefore we should use a > function like canonicalize_pathname from src/utilunix.c. Have you checked the source paths? I think canonicalize_pathname is already used and might be the cause of this little problem. I might be wrong though ;) . > We cannot use > that function because of license issues (utilunix.c is GPL, vfs is LGPL) > and dependency conflicts (src uses vfs, so vfs cannot use src; see ld(1) > for further information). If this _really_ is a problem it might be worth discussing if vfs needs to be relicensed as GPL according to paragraph 3 from the LGPL: "3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library." However I hope to avoid such license nitpicking if possible. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From wmitchell at beol.net Fri Oct 1 03:17:40 2004 From: wmitchell at beol.net (William Mitchell Jr) Date: Thu, 30 Sep 2004 23:17:40 -0400 Subject: disappearing cursor In-Reply-To: <20040930120052.GA29454@smtp-server.columbus.rr.com> References: <20040930120052.GA29454@smtp-server.columbus.rr.com> Message-ID: <20041001031740.GA21256@smtp-server.columbus.rr.com> Hi, When I use mcedit and force the no color option (mcedit -b filename) the white block cursor disappears when I use the arrow keys. /*************************************************** I should add that this only occurs in an xterm. ****************************************************/ Is this a bug? Thanks, William Mitchell --- From leonard at den.ottolander.nl Fri Oct 1 17:20:36 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 01 Oct 2004 19:20:36 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <1096640832.4778.5.camel@athlon.localdomain> References: <415C47F2.9010102@gmx.de> <1096640832.4778.5.camel@athlon.localdomain> Message-ID: <1096651235.4778.47.camel@athlon.localdomain> Hi, On Fri, 2004-10-01 at 16:27, Leonard den Ottolander wrote: > Hello Roland, > > > We should do much more error checking at this point, for > > example for "../file" or similar things. Therefore we should use a > > function like canonicalize_pathname from src/utilunix.c. Can tar archives be manipulated to include dot dot files? It definitely does not work from the command line. > Have you checked the source paths? I think canonicalize_pathname is > already used and might be the cause of this little problem. I might be > wrong though ;) . Indeed I am wrong. vfs_canon is used indirectly by tar.c, not canonicalize_pathname. > > We cannot use > > that function because of license issues (utilunix.c is GPL, vfs is LGPL) > > and dependency conflicts (src uses vfs, so vfs cannot use src; see ld(1) > > for further information). This surprises me somewhat. The name would suggest utilunix.c defines common "unix" functions. Would using canonicalize_pathname require a lot of restructuring of the code? Maybe you should mention that function in the fix me comment instead. By the way, patch seems to work, and I don't see any regressions. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mdooligan at gawab.com Sat Oct 2 13:03:33 2004 From: mdooligan at gawab.com (Miven Dooligan) Date: Sat, 02 Oct 2004 06:03:33 -0700 Subject: superfluous updating in file move dialog Message-ID: in src/file.c:move_file_file() calls progress_update_one() when it's already called copy_file_file() which also calls progress_update_one() which screws up the progress_count in the visible dialog. It does progress_count++ twice for every file (as well as progress_bytes+=add). This has been bugging me for quite a while, but I finally got around to scratching at the problem. --- ../../mc-cvs-031122/src/file.c Mon Oct 27 09:36:19 2003 +++ file.c Sun Jun 6 14:28:44 2004 @@ -1184,12 +1184,12 @@ return return_status; } - if (return_status == FILE_CONT) - return_status = progress_update_one (ctx, - progress_count, - progress_bytes, - src_stats.st_size, 1); - +// if (return_status == FILE_CONT) +// return_status = progress_update_one (ctx, +// progress_count, +// progress_bytes, +// src_stats.st_size, 1); +// return return_status; } seems to work as a temporary fix. Comments? From mdooligan at gawab.com Sat Oct 2 13:17:23 2004 From: mdooligan at gawab.com (Miven Dooligan) Date: Sat, 02 Oct 2004 06:17:23 -0700 Subject: mouse event handling Message-ID: I am having to make this tweak in screen.c for 3 years since I keep playing with mouse stuff, otherwise button down in one panel and button up in other panel doesn't work. @@ -2296,11 +2411,22 @@ } event->y -= 2; - if ((event->type & (GPM_DOWN|GPM_DRAG))){ + if ((event->type & (GPM_DOWN|GPM_DRAG|GPM_UP))){ if (panel != (WPanel *) current_dlg->current->widget) change_panel (); } Anyone know a reason why button up shouldn't know its location? Peace. From leonard at den.ottolander.nl Sat Oct 2 14:32:06 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 02 Oct 2004 16:32:06 +0200 Subject: mouse event handling In-Reply-To: References: Message-ID: <1096727525.4751.43.camel@athlon.localdomain> Hi Miven, On Sat, 2004-10-02 at 15:17, Miven Dooligan wrote: > - if ((event->type & (GPM_DOWN|GPM_DRAG))){ > + if ((event->type & (GPM_DOWN|GPM_DRAG|GPM_UP))){ Please have a closer look at the following else if. If you introduce GPM_UP here I think you should move the else if to before this check. By the way, could you provide "diff -up"s? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sun Oct 3 12:36:28 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 03 Oct 2004 14:36:28 +0200 Subject: Lingering patches Message-ID: <1096806988.4751.2.camel@athlon.localdomain> Hi Pavel, Early september I put up a couple of patches under http://www.ottolander.nl/mc-patches/proposed/ . Some of these have been merged, but an important one, mc-CVS-vcsa.patch was not. Could you please take a look and tell me which patches you did apply? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sun Oct 3 13:25:47 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 03 Oct 2004 15:25:47 +0200 Subject: Lingering patches In-Reply-To: <1096806988.4751.2.camel@athlon.localdomain> References: <1096806988.4751.2.camel@athlon.localdomain> Message-ID: <1096809947.4751.12.camel@athlon.localdomain> Hi Pavel, On Sun, 2004-10-03 at 14:36, Leonard den Ottolander wrote: > Early september I put up a couple of patches under > http://www.ottolander.nl/mc-patches/proposed/ . Some of these have been > merged, but an important one, mc-CVS-vcsa.patch was not. I've checked the patches myself and it appears only this patch was not yet applied. I've updated my patches tree. Also there is an issue with configure.ac. It contains the lines: linux*) AC_DEFINE(_GNU_SOURCE,, [Define to request GNU feature set on Linux]) Why wasn't this introduced as: linux*) AC_DEFINE(_GNU_SOURCE, 1, [Define to request GNU feature set on Linux]) ? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mdooligan at gawab.com Sun Oct 3 15:42:12 2004 From: mdooligan at gawab.com (Miven Dooligan) Date: Sun, 03 Oct 2004 08:42:12 -0700 Subject: mouse event handling Message-ID: Hi Leonard. double click -> do_enter() still work for me, all this time. if ((event->type & (GPM_DOWN | GPM_DRAG | GPM_UP ))) { if (&panel->widget != current_dlg->current) change_panel (); } if ((event->type & (GPM_DOWN|GPM_DRAG))){ /* check cursor position and scroll list */ } else if ((event->type & (GPM_UP | GPM_DOUBLE)) == (GPM_UP | GPM_DOUBLE)) { if (event->y > 0 && event->y <= lines) do_enter (panel); } But this _is_ a hack for xterm and X, for the cruddy mouse reporting. I wouldn't doubt if it interfere with other configuration. I haven't found any problem yet. From leonard at den.ottolander.nl Mon Oct 4 13:15:38 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 04 Oct 2004 15:15:38 +0200 Subject: Any progress on the broken pipe issue Message-ID: <1096895738.4777.32.camel@athlon.localdomain> Hello Roland, I was wondering if you've been looking at the broken pipe issue lately. The patch you suggested a while ago did indeed change the behaviour wrt that aspect, but sadly it did not completely suppress the broken pipe warning. Do you have any more ideas on how to fix the issue? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Oct 4 14:42:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 04 Oct 2004 16:42:27 +0200 Subject: mouse event handling In-Reply-To: References: Message-ID: <1096900947.4777.46.camel@athlon.localdomain> Hi Miven, On Sun, 2004-10-03 at 17:42, Miven Dooligan wrote: > double click -> do_enter() still work for me, all this time. Code in CVS has somewhat changed it seems. Please verify and test your patch against current CVS. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Oct 4 15:21:26 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 04 Oct 2004 17:21:26 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <415C47F2.9010102@gmx.de> References: <415C47F2.9010102@gmx.de> Message-ID: <1096903286.4777.57.camel@athlon.localdomain> Hello Roland, On Thu, 2004-09-30 at 19:52, Roland Illig wrote: > this patch fixes the second TODO item for 4.6.1. It is not perfect, but > it works. I think this can be committed. How about my other mails on this issue? Any response? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From pavelsh at mail.ru Mon Oct 4 16:39:56 2004 From: pavelsh at mail.ru (pavelsh) Date: Mon, 4 Oct 2004 22:39:56 +0600 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <1096651235.4778.47.camel@athlon.localdomain> References: <415C47F2.9010102@gmx.de> <1096640832.4778.5.camel@athlon.localdomain> <1096651235.4778.47.camel@athlon.localdomain> Message-ID: <70395030.20041004223956@mail.ru> Hello Leonard, Please. See this link ftp://ftp.berlios.de/pub/star/testscripts/ I'm searched it in http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/star.html In ftp directory was placed tar test archives. Check tar.c with it :) I searched much more bugs with this tests. -- Best regards, pavelsh mailto:pavelsh at mail.ru From roland.illig at gmx.de Mon Oct 4 18:29:08 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 4 Oct 2004 20:29:08 +0200 Subject: Any progress on the broken pipe issue References: <1096895738.4777.32.camel@athlon.localdomain> Message-ID: <015e01c4aa41$44a3d400$98e7b8d9@ingrid> > I was wondering if you've been looking at the broken pipe issue lately. > The patch you suggested a while ago did indeed change the behaviour wrt > that aspect, but sadly it did not completely suppress the broken pipe > warning. Do you have any more ideas on how to fix the issue? Hello Leonard, I am currently away from my computer, and also from the "Advanced Programming in the UNIX Environment" book which I wanted to read. I will be back on Oct 10. Then I will try to figure out what exactly happens in the case the "Broken Pipe" message appears. That's quite a complicated issue on Unix systems, involving a whole process tree, many pipes and signals. (Read the book and you'll understand that.) And I want to be sure to understand everything correctly. But then I will continue to work at it. Roland From roland.illig at gmx.de Mon Oct 4 18:35:05 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 4 Oct 2004 20:35:05 +0200 Subject: Lingering patches References: <1096806988.4751.2.camel@athlon.localdomain> <1096809947.4751.12.camel@athlon.localdomain> Message-ID: <015f01c4aa41$480b1ae0$98e7b8d9@ingrid> > Also there is an issue with configure.ac. It contains the lines: > linux*) > AC_DEFINE(_GNU_SOURCE,, [Define to request GNU feature set on > Linux]) > > Why wasn't this introduced as: > linux*) > AC_DEFINE(_GNU_SOURCE, 1, [Define to request GNU feature set on > Linux]) > ? Who else but me could have done this? ;-) cvs annotate could help in this case, and I think I also provided a useful commit message. I had problems with src/regex.c, because it first #defines _GNU_SOURCE and then #includes , which makes gcc (and maybe others) choke about the duplicate definition. But later I noticed that some other files first #define _GNU_SOURCE 1 and then #include . So the solution is to #define _GNU_SOURCE to 1 in the and repair all the files that #define _GNU_SOURCE to #define it _after_ #including . The current usage is: src/regex.c: #define _GNU_SOURCE #include {some_other_file.c}: #define _GNU_SOURCE 1 #include This should be changed to: #include #ifndef _GNU_SOURCE #define _GNU_SOURCE 1 #endif Roland From leonard at den.ottolander.nl Mon Oct 4 18:58:45 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 04 Oct 2004 20:58:45 +0200 Subject: Any progress on the broken pipe issue In-Reply-To: <015e01c4aa41$44a3d400$98e7b8d9@ingrid> References: <1096895738.4777.32.camel@athlon.localdomain> <015e01c4aa41$44a3d400$98e7b8d9@ingrid> Message-ID: <1096916325.4777.64.camel@athlon.localdomain> Hello Roland, On Mon, 2004-10-04 at 20:29, Roland Illig wrote: > I will be > back on Oct 10. Then I will try to figure out what exactly happens in the > case the "Broken Pipe" message appears. That's quite a complicated issue on > Unix systems, involving a whole process tree, many pipes and signals. (Read > the book and you'll understand that.) I believe you without reading the book ;-) . Great that you will be looking into this. Maybe we can have the development freeze and a new release right after this is fixed? I think the tar fix is good enough for now. According to Pavel Shirshov there might be a few more issues with tar.c. Not sure if these are new introductions or old issues. Seems like a good item for 4.6.2. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Oct 4 19:03:34 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 04 Oct 2004 21:03:34 +0200 Subject: Lingering patches In-Reply-To: <1096806988.4751.2.camel@athlon.localdomain> References: <1096806988.4751.2.camel@athlon.localdomain> Message-ID: <1096916614.4777.70.camel@athlon.localdomain> Hi, On Sun, 2004-10-03 at 14:36, I wrote: > Early september I put up a couple of patches under > http://www.ottolander.nl/mc-patches/proposed/ . Some of these have been > merged, but an important one, mc-CVS-vcsa.patch was not. Note that this is a well tested (on RHL and Fedora for years) and security related patch. Currently cons.saver needs to be setuid root to be able to save console contents. With this patch setuid vcsa (the owner of /dev/vcsa*) suffices to save the console contents. Much safer I would say. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Oct 4 19:16:18 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 04 Oct 2004 21:16:18 +0200 Subject: Lingering patches In-Reply-To: <015f01c4aa41$480b1ae0$98e7b8d9@ingrid> References: <1096806988.4751.2.camel@athlon.localdomain> <1096809947.4751.12.camel@athlon.localdomain> <015f01c4aa41$480b1ae0$98e7b8d9@ingrid> Message-ID: <1096917378.4777.79.camel@athlon.localdomain> Hi Roland, On Mon, 2004-10-04 at 20:35, Roland Illig wrote: > I had problems with src/regex.c, because it first #defines _GNU_SOURCE and > then #includes , which makes gcc (and maybe others) choke about > the duplicate definition. > #include > #ifndef _GNU_SOURCE > #define _GNU_SOURCE 1 > #endif src/regex.c is the only occurrence I can find. Is the 1 in the above example necessary? Doesn't the #define suffice (assuming we have the AC_DEFINE in configure.ac)? Compare Jakub's mc-CVS-vcsa patch I mentioned in this same thread. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From pavelsh at mail.ru Tue Oct 5 07:22:40 2004 From: pavelsh at mail.ru (Pavel S. Shirshov) Date: Tue, 5 Oct 2004 13:22:40 +0600 Subject: Lingering patches In-Reply-To: <1096806988.4751.2.camel@athlon.localdomain> References: <1096806988.4751.2.camel@athlon.localdomain> Message-ID: <1242801467.20041005132240@mail.ru> Hello Leonard, Sunday, October 3, 2004, 6:36:28 PM, you wrote: LdO> Early september I put up a couple of patches under LdO> http://www.ottolander.nl/mc-patches/proposed/ . Some of these have been LdO> merged, but an important one, mc-CVS-vcsa.patch was not. LdO> Could you please take a look and tell me which patches you did apply? mc-CVS-vcsa.patch was committed. Check it. -- Best regards, Pavel mailto:pavelsh at mail.ru From andrew at email.zp.ua Tue Oct 5 08:40:33 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Tue, 5 Oct 2004 11:40:33 +0300 (EEST) Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <1096903286.4777.57.camel@athlon.localdomain> Message-ID: <200410050840.i958eXlx088065@email.zp.ua> Hello Leonard, > > On Thu, 2004-09-30 at 19:52, Roland Illig wrote: > > this patch fixes the second TODO item for 4.6.1. It is not perfect, but > > it works. > > I think this can be committed. > > How about my other mails on this issue? Any response? The root of this issue is here: vfs/ChangeLog: 2003-10-26 Pavel Roskin * direntry.c (vfs_s_find_inode): Only allow search from root. Change second argument to superblock to prevent abuse. * direntry.c (vfs_s_find_entry_tree): Eliminate buffer of fixed size. Don't prepare path for vfs_s_resolve_symlink(). (vfs_s_resolve_symlink): Remove unused argument "path". * direntry.c (vfs_s_add_dots): Remove. Fix all callers. (vfs_s_free_inode): Remove support for "." and ".." entries. * ftpfs.c (dir_load): Likewise. Support for "." and ".." entries was a hack that could make the cache non-traversable from inodes to the root and cause infinite loop in vfs_s_fullpath(). Reported by Fr?d?ric L. W. Meunier Keyword is vfs_s_add_dots(). Proposed patch does not handle paths like './/./', so canonicalize_pathname() is wanted, but this solution is temporary hack only. vfs_s_find_inode() returns wrong value now and should be fixed. IMHO this issue is last to be fixed before 4.6.1 release. Also latest pipethrough changes have to be excluded form this release because of lack of testing. P.S. s/autoconf\.ac/configure.ac/ ChangeLog to fix typo. Also it will be fine to capitalize first letters after : in last entries. -- Regards, Andrew V. Samoilov. From zstingx at hotmail.com Tue Oct 5 12:53:33 2004 From: zstingx at hotmail.com (sting sting) Date: Tue, 05 Oct 2004 14:53:33 +0200 Subject: Jedit and MidnightCommander Message-ID: Hello, My aim is taht when pressing "Enter" while in MC we will open a text file with JEdit. (On Linux). Following a post in this list I had updated my .binding file so it contains now 2 additional lines: shell/.txt Open=jedit %f It does open the text file in JEdit when pressing Enter button while in MC; the problem is that if there is one instance of JEdit running, it does not open it in that instance, but opens a new instance. Is there a way to avoid opening a second (and third, and so on) instance ? JEDit is relativel heavy (written in Java) so this poses a memory burden and takes time regards, Sting _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From leonard at den.ottolander.nl Tue Oct 5 13:34:29 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 05 Oct 2004 15:34:29 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <200410050840.i958eXlx088065@email.zp.ua> References: <200410050840.i958eXlx088065@email.zp.ua> Message-ID: <1096983268.4812.30.camel@athlon.localdomain> Hello Andrew, On Tue, 2004-10-05 at 10:40, Andrew V. Samoilov wrote: > Proposed patch does not handle paths like './/./', so canonicalize_pathname() > is wanted, but this solution is temporary hack only. > vfs_s_find_inode() returns wrong value now and should be fixed. Would the same be true if canonicalize_pathname() were used? What about the license issues Roland mentions? Are those a real concern? > IMHO this issue is last to be fixed before 4.6.1 release. The broken pipe issue is still being worked on as Roland reported yesterday. Don't you want to have that fixed before 4.6.1? > Also latest pipethrough changes have to be excluded form this release because > of lack of testing. I believe the pipethrough code to be unused at this point. I forgot what Roland's rationale was to introduce it. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From eth0 at o2.pl Tue Oct 5 14:19:42 2004 From: eth0 at o2.pl (q#) Date: Tue, 5 Oct 2004 16:19:42 +0200 Subject: hash (sharp) in file and dir names over vfs.. Message-ID: <20041005141942.GA16841@hindus.hstl5.put.poznan.pl> Hi, I've tested mc and found some problems with "#" in file and dir names over vfs. My tests cover only sshfs (fish?), ftpfs, tarfs part of vfs. Fish has also problem with symlinks. I could not view symlink pointing to regular file. Dir-links however works okay, but they are visible as normal directories. I created some test archive, where you can see how problem looks like. You can also unpack .tgz and browse it over sshfs and ftpfs for full picture. My second issue are directories with spaces in prompt. For ex. when we have "some dir" and in prompt we write 'rm -rf ' and press CTRL+ENTER, result will be 'rm -rf some\ dir ', and execute it (ENTER) dir will disapeare. That's ok. But when we write 'cd dome\ dir', built-in command don't understand it properly, and mc shows 'no such file or...' Test file: http://kubek.eu.org/~hns/pub/mc/mc-tests.tgz -- best regards q# From andrew at email.zp.ua Tue Oct 5 14:46:51 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Tue, 5 Oct 2004 17:46:51 +0300 (EEST) Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <1096983268.4812.30.camel@athlon.localdomain> Message-ID: <200410051446.i95Ekp7P000900@email.zp.ua> Hello Leonard, > > On Tue, 2004-10-05 at 10:40, Andrew V. Samoilov wrote: > > Proposed patch does not handle paths like './/./', so canonicalize_pathname() > > is wanted, but this solution is temporary hack only. > > vfs_s_find_inode() returns wrong value now and should be fixed. > > Would the same be true if canonicalize_pathname() were used? Well, now we need to handle ./ everywhere where it could happen. Simple testcase: $ touch abc ; echo abc | cpio -cp > dot.cpio Edit dot.cpio and replace abc with ./b. Tap into dot.cpio. I think this will be definitely understand that tar.c is wrong place to fix this issue. > What about the license issues Roland mentions? Are those a real concern? I think $ grep canonocalize_pathname vfs/*.c clears this completely. > > > IMHO this issue is last to be fixed before 4.6.1 release. > > The broken pipe issue is still being worked on as Roland reported > yesterday. Don't you want to have that fixed before 4.6.1? IMHO this is not blocker issue. > > Also latest pipethrough changes have to be excluded form this release because > > of lack of testing. > > I believe the pipethrough code to be unused at this point. I forgot what > Roland's rationale was to introduce it. It could be included together via configure option. -- Regards, Andrew V. Samoilov. From andrew at email.zp.ua Tue Oct 5 15:04:47 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Tue, 5 Oct 2004 18:04:47 +0300 (EEST) Subject: cpio.c issues Message-ID: <200410051504.i95F4lsS001563@email.zp.ua> -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cpio.c.patch URL: From leonard at den.ottolander.nl Tue Oct 5 15:12:19 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 05 Oct 2004 17:12:19 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <200410051446.i95Ekp7P000900@email.zp.ua> References: <200410051446.i95Ekp7P000900@email.zp.ua> Message-ID: <1096989139.4812.43.camel@athlon.localdomain> Hi Andrew, On Tue, 2004-10-05 at 16:46, Andrew V. Samoilov wrote: > Edit dot.cpio and replace abc with ./b. Tap into dot.cpio. > I think this will be definitely understand that tar.c is wrong place to fix > this issue. Hadn't tried that. cpio will remove the leading dots if you feed it dot slash files from the command line. But I agree with you fixing every individual case is probably not what we want to do. > > What about the license issues Roland mentions? Are those a real concern? > > I think > $ grep canonocalize_pathname vfs/*.c > clears this completely. Obviously being used. Which does not say that Roland could not technically be correct that LGPL can't link to GPL. > > The broken pipe issue is still being worked on as Roland reported > > yesterday. Don't you want to have that fixed before 4.6.1? > > IMHO this is not blocker issue. Not in my mind either. It mostly depends on how long it takes to fix. > It could be included together via configure option. I remember. The extension menu right? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Oct 5 16:08:22 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 05 Oct 2004 18:08:22 +0200 Subject: Various issues with viewing man pages Message-ID: <1096992502.4812.63.camel@athlon.localdomain> Hi, I'm seeing various issues when viewing around in /usr/share/man. Errors like "iconv: illegal input sequence at position 1629" for en/man2/close.2.gz (FC1) and ":1: realpath on `man2/_exit.2' failed: troff: Failed assertion at line 118, file `errarg.cc'. groff: troff: Aborted" for man2/_Exit.2.gz. These issues are also present in 4.6.0 (FC1's mc-4.6.0-17.fc1). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Oct 5 19:11:53 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 05 Oct 2004 21:11:53 +0200 Subject: extfs shell scripts fixed patch Message-ID: <1097003513.4812.72.camel@athlon.localdomain> Hi, Next to the perl script quote fixes (CAN-2004-0494) SuSE has released fixes to three shell scripts in extfs. These are audio.in, hp48.in and trpm. Fixes to the first seem complete, but not the fixes to trpm. Although I have no idea how to test trpm I think the attached patch should be more complete than SuSE's fix. Please check the fixes to trpm for validity and completeness. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS20040925-extfs.shell.patch Type: text/x-patch Size: 13565 bytes Desc: not available URL: From mdooligan at gawab.com Tue Oct 5 21:33:07 2004 From: mdooligan at gawab.com (Miven Dooligan) Date: Tue, 05 Oct 2004 14:33:07 -0700 Subject: mouse event handling (with new cvs) Message-ID: Indeed you are correct that doubleclick stop working in new cvs with that tweak. I was using snapshot a month or two old. Oh well. If anyone but me care whether button up in xterm select correct panel, I will submit a proper patch for new cvs. -- Peace and Cheer. From andrew at email.zp.ua Wed Oct 6 09:28:09 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 6 Oct 2004 12:28:09 +0300 (EEST) Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <1096989139.4812.43.camel@athlon.localdomain> Message-ID: <200410060928.i969S9A6032842@email.zp.ua> Hi Leonard, > > > What about the license issues Roland mentions? Are those a real concern? > > > > I think > > $ grep canonocalize_pathname vfs/*.c > > clears this completely. > > Obviously being used. Which does not say that Roland could not > technically be correct that LGPL can't link to GPL. It will be a big trouble for libvfs because of concat_dir_and_file(), wipe_password(), load_anon_passwd(), {enable,disable}_interrupt_key(), exist_file(), mc_mkstemps(), input_dialog(), decompress_extension(), get_compression_type(), {open,close}_error_pipe(), name_quote(), my_system(), mc_home and so on. BTW vfs/local.c has no license note at all. > I remember. The extension menu right? ??? -- Regards, Andrew V. Samoilov. From andrew at email.zp.ua Wed Oct 6 10:36:38 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 6 Oct 2004 13:36:38 +0300 (EEST) Subject: extfs shell scripts fixed patch In-Reply-To: <1097003513.4812.72.camel@athlon.localdomain> Message-ID: <200410061036.i96AacqB035396@email.zp.ua> > Hi, > > Next to the perl script quote fixes (CAN-2004-0494) SuSE has released > fixes to three shell scripts in extfs. These are audio.in, hp48.in and > trpm. Fixes to the first seem complete, but not the fixes to trpm. audio.in fix does not cure $, " and ` in the filenames. -- Regards, Andrew V. Samoilov. From leonard at den.ottolander.nl Wed Oct 6 13:53:23 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 06 Oct 2004 15:53:23 +0200 Subject: extfs shell scripts fixed patch In-Reply-To: <200410061036.i96AacqB035396@email.zp.ua> References: <200410061036.i96AacqB035396@email.zp.ua> Message-ID: <1097070802.4823.43.camel@athlon.localdomain> Hi Andrew, On Wed, 2004-10-06 at 12:36, Andrew V. Samoilov wrote: > audio.in fix does not cure $, " and ` in the filenames. Right. Even more incomplete than I thought. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Oct 6 13:54:37 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 06 Oct 2004 15:54:37 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <200410060928.i969S9A6032842@email.zp.ua> References: <200410060928.i969S9A6032842@email.zp.ua> Message-ID: <1097070876.4823.48.camel@athlon.localdomain> Hello Andrew, On Wed, 2004-10-06 at 11:28, Andrew V. Samoilov wrote: > It will be a big trouble for libvfs because of concat_dir_and_file(), It will be or it is? Anyway, if there is a serious license issue we could relicense vfs under the GPL. Do you think that is necessary? > BTW vfs/local.c has no license note at all. Interesting. > > I remember. The extension menu right? > > ??? I believe Roland used pipethrough.c for a new version of the paste output from external command in the editor. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Wed Oct 6 14:15:54 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 6 Oct 2004 17:15:54 +0300 (EEST) Subject: Various issues with viewing man pages In-Reply-To: <1096992502.4812.63.camel@athlon.localdomain> Message-ID: <200410061415.i96EFsjD042347@email.zp.ua> Hi, > I'm seeing various issues when viewing around in /usr/share/man. Errors > like "iconv: illegal input sequence at position 1629" for > en/man2/close.2.gz (FC1) and ":1: realpath on > `man2/_exit.2' failed: troff: Failed assertion at line 118, file > `errarg.cc'. groff: troff: Aborted" for man2/_Exit.2.gz. > > These issues are also present in 4.6.0 (FC1's mc-4.6.0-17.fc1). I am sure these issues are not related to mc. Try $ LANG=en man 2 close _exit -- Regards, Andrew V. Samoilov. From leonard at den.ottolander.nl Wed Oct 6 14:42:52 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 06 Oct 2004 16:42:52 +0200 Subject: Various issues with viewing man pages In-Reply-To: <200410061415.i96EFsjD042347@email.zp.ua> References: <200410061415.i96EFsjD042347@email.zp.ua> Message-ID: <1097073771.5021.2.camel@athlon.localdomain> Hi Andrew, On Wed, 2004-10-06 at 16:15, Andrew V. Samoilov wrote: > > ":1: realpath on > > `man2/_exit.2' failed: troff: Failed assertion at line 118, file > > `errarg.cc'. groff: troff: Aborted" for man2/_Exit.2.gz. > I am sure these issues are not related to mc. > Try > $ LANG=en man 2 close _exit The issue with en/man2/close.2.gz indeed seems to be a code page issue. Using UTF-8 instead of ISO-8859-15 fixes the issue (strange for an english man page that this would make a difference, but ok). The other issue with man2/_Exit.2.gz remains. Note that this is a symlink to _exit.2.gz. Viewing the latter doesn't give me any problems, viewing _Exit.2.gz does still give me the realpath issue. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Wed Oct 6 15:27:15 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 6 Oct 2004 18:27:15 +0300 (EEST) Subject: Various issues with viewing man pages In-Reply-To: <1097073771.5021.2.camel@athlon.localdomain> Message-ID: <200410061527.i96FRFlp044500@email.zp.ua> Hi Andrew, > The other issue with man2/_Exit.2.gz remains. Note that this is a > symlink to _exit.2.gz. Viewing the latter doesn't give me any problems, > viewing _Exit.2.gz does still give me the realpath issue. Well, this is groff issue. You will have the same error with man. -- Regards, Andrew V. Samoilov. From leonard at den.ottolander.nl Wed Oct 6 16:01:52 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 06 Oct 2004 18:01:52 +0200 Subject: FTP password visibility fixes Message-ID: <1097078511.5513.4.camel@athlon.localdomain> Hi, I noticed that the new mc maintainer for Red Hat/Fedora, Jindrich Novy has made some patches to hide the FTP password in various dialogs. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131088 and http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs , "[RFE] hide password in directory hotlist URL". I requested Jindrich to create a fix to hide the password in the directory hotlist. Maybe it's a good idea to apply these patches before 4.6.1, as they are security related. Anybody cares to test these patches? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Oct 6 16:15:58 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 06 Oct 2004 18:15:58 +0200 Subject: Various issues with viewing man pages In-Reply-To: <200410061527.i96FRFlp044500@email.zp.ua> References: <200410061527.i96FRFlp044500@email.zp.ua> Message-ID: <1097079358.5513.11.camel@athlon.localdomain> Hello Andrew, > > The other issue with man2/_Exit.2.gz remains. Note that this is a > > symlink to _exit.2.gz. Viewing the latter doesn't give me any problems, > > viewing _Exit.2.gz does still give me the realpath issue. > > Well, this is groff issue. You will have the same error with man. Nope. I have no issues running $ man [2] _Exit Viewing (F3) or entering the man page from mc does give me that error. Might be a combined issue though. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Wed Oct 6 23:48:19 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 7 Oct 2004 02:48:19 +0300 (EEST) Subject: FTP password visibility fixes In-Reply-To: <1097078511.5513.4.camel@athlon.localdomain> Message-ID: <200410062348.i96NmJfx057924@email.zp.ua> Hi, > I noticed that the new mc maintainer for Red Hat/Fedora, Jindrich Novy > has made some patches to hide the FTP password in various dialogs. See > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131088 and > http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs , "[RFE] hide password > in directory hotlist URL". > > I requested Jindrich to create a fix to hide the password in the > directory hotlist. Maybe it's a good idea to apply these patches before > 4.6.1, as they are security related. Anybody cares to test these > patches? There is some issues discussed at bugzilla. But attached patch has to be applied just now. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: util.c.patch URL: From andrew at email.zp.ua Wed Oct 6 23:48:19 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 7 Oct 2004 02:48:19 +0300 (EEST) Subject: FTP password visibility fixes In-Reply-To: <1097078511.5513.4.camel@athlon.localdomain> Message-ID: <200410062348.i96NmJiP057937@email.zp.ua> Hi, > I noticed that the new mc maintainer for Red Hat/Fedora, Jindrich Novy > has made some patches to hide the FTP password in various dialogs. See > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131088 and > http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs , "[RFE] hide password > in directory hotlist URL". > > I requested Jindrich to create a fix to hide the password in the > directory hotlist. Maybe it's a good idea to apply these patches before > 4.6.1, as they are security related. Anybody cares to test these > patches? There is some issues discussed at bugzilla. But attached patch has to be applied just now. -- Regards, Andrew V. Samoilov. From ptsekov at gmx.net Thu Oct 7 08:10:46 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 7 Oct 2004 10:10:46 +0200 Subject: disappearing cursor In-Reply-To: <20041001031740.GA21256@smtp-server.columbus.rr.com> References: <20040930120052.GA29454@smtp-server.columbus.rr.com> <20041001031740.GA21256@smtp-server.columbus.rr.com> Message-ID: Hello, On Thu, 30 Sep 2004, William Mitchell Jr wrote: > When I use mcedit and force the no color option (mcedit -b filename) > > the white block cursor disappears when I use the arrow keys. > > > /*************************************************** > > I should add that this only occurs in an xterm. > > ****************************************************/ Can you provide the output of `mcedit -V'. Under which OS do you see this problem ? From ptsekov at gmx.net Thu Oct 7 08:21:38 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 7 Oct 2004 10:21:38 +0200 Subject: suggestion In-Reply-To: <1096813412.14121.1.camel@localhost> References: <1096813412.14121.1.camel@localhost> Message-ID: Hello, On Sun, 3 Oct 2004, Michal Bozalek wrote: > Suggest increasing the LINES and COLS limit in slint.c line 185 to over > 300 as new displays (mine is 1680x1050) have over 255 COLS/LINES I remember this was done on purpose as you can see here: http://mail.gnome.org/archives/mc-devel/2003-January/msg00136.html As a result the following changes were made: 2003-01-23 Pavel Roskin * slint.c (slang_init): Limit screen size to 255x255 because of S-Lang limitations. Reported by Tero Peippola Maybe now it is time to find a solution to this problem ? Maybe it is already fixed in S-Lang ? From ptsekov at gmx.net Thu Oct 7 08:24:17 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 7 Oct 2004 10:24:17 +0200 Subject: [PATCH]: Add support for changing drives in Cygwin - second try In-Reply-To: References: <20040916175939.GA32442@ugly.local> Message-ID: On Thu, 23 Sep 2004, Pavel Tsekov wrote: > Hello, > > Here is an updated patch - please, review. I've made the following > changes: Ping ? I would like to see this in 4.6.1 if possible. From leonard at den.ottolander.nl Thu Oct 7 13:43:17 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 07 Oct 2004 15:43:17 +0200 Subject: [PATCH]: Add support for changing drives in Cygwin - second try In-Reply-To: References: <20040916175939.GA32442@ugly.local> Message-ID: <1097156597.4814.9.camel@athlon.localdomain> Hi Pavel, On Thu, 2004-10-07 at 10:24, Pavel Tsekov wrote: > > Here is an updated patch - please, review. I've made the following > > changes: > Ping ? I would like to see this in 4.6.1 if possible. Yes, resources are limited, that's why this has lingered. Sorry, but I will not review this patch as I've never worked with cygwin. Anybody? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From eth0 at o2.pl Fri Oct 8 00:27:30 2004 From: eth0 at o2.pl (q#) Date: Fri, 8 Oct 2004 02:27:30 +0200 Subject: mc, ftpfs wrong progress calculation of symlink with "[x] follow symlink" opt Message-ID: <20041008002730.GA16444@hindus.hstl5.put.poznan.pl> Hi, I will try to explain how to reconstruct situation: cd ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.3-BETA7/packages/editors then we select openoffice-*.tbz (if bigger file, than easy to see problem) as you can see all files in ftp://ftp.../editors/ are symlinks, which are very small, but OOo is big. Then we start copying it, but _with_ "follow symlink" option in copy dialog. "File" progress bar compute "%" okey, but "Bytes" are calculated from symlinks, I think that is wrong because it show in few seconds tha total proces is at 100% done, but thats not true. $ mc -V GNU Midnight Commander 4.6.1-pre1 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish With builtin Editor Using included S-Lang library with termcap database With subshell support as default With support for background operations With mouse support on xterm With support for X11 events With internationalization support With multiple codepages support $ dmesg | head -n 1 OpenBSD 3.6-current (GENERIC) #0: Wed Sep 29 08:20:27 CEST 2004 -- best regards q# From andrew at email.zp.ua Fri Oct 8 11:26:48 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 8 Oct 2004 14:26:48 +0300 (EEST) Subject: [PATCH]: Add support for changing drives in Cygwin - second try In-Reply-To: Message-ID: <200410081126.i98BQmMA023498@email.zp.ua> Hello, > Ping ? I would like to see this in 4.6.1 if possible. I have no cygwin, but I reviewed this patch. Why you don't use glib memory manipulation functions and gettext? Also it is possible to use MSG_ERROR intead of hardcoded "Error" with message(). -- Regards, Andrew V. Samoilov. From ptsekov at gmx.net Fri Oct 8 10:09:33 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 8 Oct 2004 12:09:33 +0200 Subject: [PATCH]: Add support for changing drives in Cygwin - second try In-Reply-To: <200410081126.i98BQmMA023498@email.zp.ua> References: <200410081126.i98BQmMA023498@email.zp.ua> Message-ID: Hello, On Fri, 8 Oct 2004, Andrew V. Samoilov wrote: > Hello, > > > Ping ? I would like to see this in 4.6.1 if possible. > > I have no cygwin, but I reviewed this patch. > Why you don't use glib memory manipulation functions and gettext? > Also it is possible to use MSG_ERROR intead of hardcoded "Error" with message(). I'll update the patch as you suggest. Thanks! From jnovy at redhat.com Fri Oct 8 13:47:55 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 08 Oct 2004 15:47:55 +0200 Subject: FTP password visibility fixes Message-ID: <1097243275.22130.40.camel@localhost.localdomain> Hi, Leonard told me to post the ftp password visibility related patch also to mc-devel. The following patch fixes possible displaying of passwords in ftp, fish, mc, smb urls in hotlist and introduces a new implementation of strip_password () [based on patch by Jakub Jelinek] which doesn't modify characters in the input path at all because it uses mem*() functions instead of str*(). It also eliminates possible passwords displayed in paths in error messages in case of chdir failure or delete, copy dialogs, etc. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ --- mc-4.6.1-20041008/src/subshell.c.strippwd 2004-10-08 10:17:41.000000000 +0200 +++ mc-4.6.1-20041008/src/subshell.c 2004-10-08 13:06:10.306864832 +0200 @@ -788,9 +788,12 @@ feed_subshell (QUIETLY, FALSE); if (subshell_alive && strcmp (subshell_cwd, current_panel->cwd) - && strcmp (current_panel->cwd, ".")) + && strcmp (current_panel->cwd, ".")) { + char *cwd = strip_password(g_strdup(current_panel->cwd), 1); fprintf (stderr, _("Warning: Cannot change to %s.\n"), - current_panel->cwd); + cwd); + g_free(cwd); + } if (reset_prompt) prompt_pos = 0; --- mc-4.6.1-20041008/src/util.c.strippwd 2004-10-08 10:17:41.287669344 +0200 +++ mc-4.6.1-20041008/src/util.c 2004-10-08 12:32:35.674135560 +0200 @@ -340,6 +340,22 @@ return x; } +/* + * path_trunc() is the same as name_trunc() above but + * it deletes possible password from path for security + * reasons. + */ +const char * +path_trunc (const char *path, int trunc_len) { + const char *ret; + char *secure_path = strip_password(g_strdup(path), 1); + + ret = name_trunc(secure_path, trunc_len); + g_free(secure_path); + + return ret; +} + const char *size_trunc (double size) { static char x [BUF_TINY]; @@ -513,6 +529,7 @@ {"/#mc:", 5}, {"ftp://", 6}, {"/#smb:", 6}, + {"/#sh:", 5}, }; char *at, *inner_colon, *dir; size_t i; @@ -520,29 +537,29 @@ for (i = 0; i < sizeof (prefixes)/sizeof (prefixes[0]); i++) { char *q; + size_t host_len; if (has_prefix) { if((q = strstr (p, prefixes[i].name)) == 0) continue; else p = q + prefixes[i].len; - }; + } if ((dir = strchr (p, PATH_SEP)) != NULL) - *dir = '\0'; + host_len = dir - p; + else + host_len = strlen (p); + /* search for any possible user */ - at = strrchr (p, '@'); + at = memchr (p, '@', host_len); /* We have a username */ if (at) { - *at = 0; - inner_colon = strchr (p, ':'); - *at = '@'; + inner_colon = memchr (p, ':', at - p); if (inner_colon) - strcpy (inner_colon, at); + memmove (inner_colon, at, strlen(at) + 1 ); } - if (dir) - *dir = PATH_SEP; break; } return (result); --- mc-4.6.1-20041008/src/filegui.c.strippwd 2004-10-08 10:17:41.275671168 +0200 +++ mc-4.6.1-20041008/src/filegui.c 2004-10-08 12:29:33.974758064 +0200 @@ -68,6 +68,7 @@ #include "fileopctx.h" /* FILE_CONT */ #include "filegui.h" #include "key.h" /* get_event */ +#include "util.h" /* strip_password() */ /* }}} */ @@ -423,7 +424,8 @@ /* }}} */ -#define truncFileString(ui, s) name_trunc (s, ui->eta_extra + 47) +#define truncFileString(ui, s) name_trunc (s, ui->eta_extra + 47) +#define truncFileStringSecure(ui, s) path_trunc (s, ui->eta_extra + 47) FileProgressStatus file_progress_show_source (FileOpContext *ctx, const char *s) @@ -472,7 +474,7 @@ if (s != NULL) { label_set_text (ui->file_label[1], _("Target")); - label_set_text (ui->file_string[1], truncFileString (ui, s)); + label_set_text (ui->file_string[1], truncFileStringSecure (ui, s)); return check_progress_buttons (ctx); } else { label_set_text (ui->file_label[1], ""); @@ -494,7 +496,7 @@ ui = ctx->ui; label_set_text (ui->file_label[0], _("Deleting")); - label_set_text (ui->file_label[0], truncFileString (ui, s)); + label_set_text (ui->file_label[0], truncFileStringSecure (ui, s)); return check_progress_buttons (ctx); } @@ -854,6 +856,7 @@ int source_easy_patterns = easy_patterns; char *source_mask, *orig_mask, *dest_dir, *tmpdest; const char *error; + char *def_text_secure; struct stat buf; int val; QuickDialog Quick_input; @@ -872,6 +875,9 @@ fmd_widgets[FMCB22].result = &ctx->stable_symlinks; fmd_widgets[FMCB21].result = &ctx->dive_into_subdirs; + /* filter out a possible password from def_text */ + def_text_secure = strip_password(g_strdup(def_text), 1); + /* Create the dialog */ ctx->stable_symlinks = 0; @@ -885,15 +891,18 @@ Quick_input.i18n = 1; Quick_input.widgets = fmd_widgets; fmd_widgets[FMDI0].text = text; - fmd_widgets[FMDI2].text = def_text; + fmd_widgets[FMDI2].text = def_text_secure; fmd_widgets[FMDI2].str_result = &dest_dir; fmd_widgets[FMDI1].str_result = &source_mask; *do_background = 0; ask_file_mask: - if ((val = quick_dialog_skip (&Quick_input, SKIP)) == B_CANCEL) + if ((val = quick_dialog_skip (&Quick_input, SKIP)) == B_CANCEL) { + g_free(def_text_secure); return 0; + } + g_free(def_text_secure); if (ctx->follow_links) ctx->stat_func = (mc_stat_fn) mc_stat; --- mc-4.6.1-20041008/src/hotlist.c.strippwd 2004-10-08 10:17:41.252674664 +0200 +++ mc-4.6.1-20041008/src/hotlist.c 2004-10-08 12:57:22.674077208 +0200 @@ -761,7 +761,7 @@ /* should be inserted before first item */ new->next = current; current_group->head = new; - } else if (pos == 1) { /* befor current */ + } else if (pos == 1) { /* before current */ struct hotlist *p = current_group->head; while (p->next != current) @@ -905,7 +905,8 @@ int ret; /* Take current directory as default value for input fields */ - title = url = current_panel->cwd; + url = strip_password(g_strdup(current_panel->cwd), 1); + title = g_strdup(url); ret = add_new_entry_input (_("New hotlist entry"), _("Directory label"), _("Directory path"), "[Hotlist]", &title, &url); @@ -919,6 +920,9 @@ add2hotlist (g_strdup (title),g_strdup (url), HL_TYPE_ENTRY, 1); hotlist_state.modified = 1; + + g_free(title); + g_free(url); } static int add_new_group_input (const char *header, const char *label, char **result) @@ -1003,15 +1007,16 @@ { char *prompt, *label; const char *cp = _("Label for \"%s\":"); + char *label_string = strip_password(g_strdup(current_panel->cwd), 1); int l = mbstrlen (cp); - prompt = g_strdup_printf (cp, name_trunc (current_panel->cwd, COLS-2*UX-(l+8))); - label = input_dialog (_(" Add to hotlist "), prompt, current_panel->cwd); + prompt = g_strdup_printf (cp, name_trunc (label_string, COLS-2*UX-(l+8))); + label = input_dialog (_(" Add to hotlist "), prompt, label_string); g_free (prompt); if (!label || !*label) return; - add2hotlist (label,g_strdup (current_panel->cwd), HL_TYPE_ENTRY, 0); + add2hotlist (label, label_string, HL_TYPE_ENTRY, 0); hotlist_state.modified = 1; } --- mc-4.6.1-20041008/src/file.c.strippwd 2004-09-25 15:46:23.000000000 +0200 +++ mc-4.6.1-20041008/src/file.c 2004-10-08 10:17:41.298667672 +0200 @@ -1111,8 +1111,8 @@ msize = 40; msize /= 2; - strcpy (st, name_trunc (s, msize)); - strcpy (dt, name_trunc (d, msize)); + strcpy (st, path_trunc (s, msize)); + strcpy (dt, path_trunc (d, msize)); message (1, MSG_ERROR, _(" `%s' and `%s' are the same file "), st, dt); do_refresh (); @@ -1229,8 +1229,8 @@ msize = 40; msize /= 2; - strcpy (st, name_trunc (s, msize)); - strcpy (dt, name_trunc (d, msize)); + strcpy (st, path_trunc (s, msize)); + strcpy (dt, path_trunc (d, msize)); message (1, MSG_ERROR, _(" `%s' and `%s' are the same directory "), st, dt); do_refresh (); @@ -2157,7 +2157,7 @@ file_error (const char *format, const char *file) { g_snprintf (cmd_buf, sizeof (cmd_buf), format, - name_trunc (file, 30), unix_error_string (errno)); + path_trunc (file, 30), unix_error_string (errno)); return do_file_error (cmd_buf); } @@ -2169,8 +2169,8 @@ char nfile1[16]; char nfile2[16]; - strcpy (nfile1, name_trunc (file1, 15)); - strcpy (nfile2, name_trunc (file2, 15)); + strcpy (nfile1, path_trunc (file1, 15)); + strcpy (nfile2, path_trunc (file2, 15)); g_snprintf (cmd_buf, sizeof (cmd_buf), format, nfile1, nfile2, unix_error_string (errno)); @@ -2191,7 +2191,7 @@ " Delete it recursively? ") : _("\n Background process: Directory not empty \n" " Delete it recursively? "); - text = g_strconcat (_(" Delete: "), name_trunc (s, 30), " ", (char *) NULL); + text = g_strconcat (_(" Delete: "), path_trunc (s, 30), " ", (char *) NULL); if (safe_delete) query_set_sel (1); --- mc-4.6.1-20041008/src/command.c.strippwd 2004-10-08 13:19:05.000000000 +0200 +++ mc-4.6.1-20041008/src/command.c 2004-10-08 13:27:24.247196464 +0200 @@ -179,8 +179,10 @@ } } 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 "), - &cmd [3], unix_error_string (errno)); + d, unix_error_string (errno)); + g_free(d); return; } } --- mc-4.6.1-20041008/src/screen.c.strippwd 2004-10-08 13:13:06.000000000 +0200 +++ mc-4.6.1-20041008/src/screen.c 2004-10-08 13:15:05.096564440 +0200 @@ -2293,8 +2293,10 @@ current_panel = panel; panel->active = 1; if (mc_chdir (panel->cwd) != 0) { + char *cwd = strip_password (g_strdup(panel->cwd), 1); message (1, MSG_ERROR, _(" Cannot chdir to \"%s\" \n %s "), - panel->cwd, unix_error_string (errno)); + cwd, unix_error_string (errno)); + g_free(cwd); } else subshell_chdir (panel->cwd); --- mc-4.6.1-20041008/src/util.h.strippwd 2004-10-08 10:17:41.248675272 +0200 +++ mc-4.6.1-20041008/src/util.h 2004-10-08 13:35:20.925730312 +0200 @@ -28,6 +28,11 @@ * Return static buffer, no need to free() it. */ const char *name_trunc (const char *txt, int trunc_len); +/* path_trunc() is the same as name_trunc() above but + * it deletes possible password from path for security + * reasons. */ +const char *path_trunc (const char *path, int trunc_len); + /* return a static string representing size, appending "K" or "M" for * big sizes. * NOTE: uses the same static buffer as size_trunc_sep. */ From leonard at den.ottolander.nl Sat Oct 9 11:52:11 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 09 Oct 2004 13:52:11 +0200 Subject: FTP password visibility fixes In-Reply-To: <1097243275.22130.40.camel@localhost.localdomain> References: <1097243275.22130.40.camel@localhost.localdomain> Message-ID: <1097322731.4788.7.camel@athlon.localdomain> Hello Jindrich, On Fri, 2004-10-08 at 15:47, Jindrich Novy wrote: > Leonard told me to post the ftp password visibility related patch also > to mc-devel. Well, asked :) . > The following patch fixes possible displaying of passwords in ftp, fish, > mc, smb urls in hotlist and introduces a new implementation of > strip_password () [based on patch by Jakub Jelinek] which doesn't modify > characters in the input path at all because it uses mem*() functions > instead of str*(). Could you please provide diff -up s and attach instead of inline? The former for readability and the latter to avoid line wrapping problems when extracting the patch. TIA. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From dmi_a at qnx.org.ru Sat Oct 9 14:49:16 2004 From: dmi_a at qnx.org.ru (Dmitry Alexeyev) Date: Sat, 9 Oct 2004 18:49:16 +0400 Subject: Is bug in patchfs? In-Reply-To: <1209122612.20040929022232@mail.ru> References: <1209122612.20040929022232@mail.ru> Message-ID: <200410091849.16854.dmi_a@qnx.org.ru> On Wednesday 29 September 2004 00:22, pavelsh wrote: > Hello, > > mcqnx.diff is a test case for reproduce patchfs error. > > For reproduce: > 1) Open mcqnx.diff > 2) View (F3) any file from it. > 3) You can 'yyyyyyyyyyyyyyyy' instead file content. Hi Pavel, Not patchfs bug - I'd suggest some buffering bug. Run patchfs this way (it is simple perl script): ./patchfs copyout mcqnx.diff ./mc/src/key.c.diff test.c You will see test.c containing key.c.diff WBR Dmitry From ptsekov at gmx.net Sun Oct 10 08:40:07 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Sun, 10 Oct 2004 10:40:07 +0200 Subject: suggestion In-Reply-To: References: <1096813412.14121.1.camel@localhost> Message-ID: Hello, On Thu, 7 Oct 2004, Pavel Tsekov wrote: > On Sun, 3 Oct 2004, Michal Bozalek wrote: > > > Suggest increasing the LINES and COLS limit in slint.c line 185 to over > > 300 as new displays (mine is 1680x1050) have over 255 COLS/LINES [...] > Maybe now it is time to find a solution to this problem ? Maybe it is > already fixed in S-Lang ? S-Lang 1.4.7 or newer allows for maximum of 512 columns. 1.4.7 introduces the new macro definitions SLTT_MAX_SCREEN_ROWS and SLTT_MAX_SCREEN_COLS, which replace the old macro MAX_SCREEN_SIZE. Both of these new macros have a value of 512. 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. Any thoughts ? From eth0 at o2.pl Sun Oct 10 16:44:17 2004 From: eth0 at o2.pl (q#) Date: Sun, 10 Oct 2004 18:44:17 +0200 Subject: simple patch for lib/mc.ext.in Message-ID: <20041010164417.GA28530@hindus.hstl5.put.poznan.pl> Hi, It adds: * view images with identify || file * tar archive with uppercase * bittorrent files view * playlist files (with xmms or mplayer) * .WMA audio files (with mplayer) * .ogm video (with mplayer) * .qt video (with mplayer) * minor stuff -- best regards q# -------------- next part -------------- --- mc.ext.in Fri Apr 2 09:22:18 2004 +++ mc.ext.in.new Sun Oct 10 18:33:34 2004 @@ -222,14 +222,14 @@ include/image Open=if [ "$DISPLAY" = "" ]; then zgv %f; else (gqview %f &); fi - View=%view{ascii} identify %f + View=%view{ascii} identify %f 2>/dev/null || file %f 2>/dev/null #View=%view{ascii} asciiview %f ### Sound files ### -regex/\.(wav|WAV|Wav|snd|SND|Snd|voc|VOC|Voc|au|AU|Au)$ - Open=play %f +regex/\.([wW][aA][vV]|[sS][nN][dD]|[vV][oO][cC]|[aA][uU])$ + Open=if [ "$DISPLAY" = "" ]; then play %f; else (exec xmms -e %f 1>/dev/null 2>&1 &); fi regex/\.(mod|MOD|Mod|s3m|S3M|S3m|xm|XM|Xm)$ Open=mikmod %f @@ -238,30 +238,43 @@ regex/\.(wav22|WAV22)$ Open=vplay -s 22 %f -regex/\.(mp3|MP3|Mp3)$ - Open=if [ "$DISPLAY" = "" ]; then mpg123 %f; else (xmms %f &); fi +regex/\.([mM][pP]3)$ + Open=if [ "$DISPLAY" = "" ]; then mpg123 %f; else (exec xmms %f &); fi View=%view{ascii} mpg123 -vtn1 %f 2>&1 | sed -n '/^Title/,/^Comment/p;/^MPEG/,/^Audio/p' + #View=%view{ascii} ( file -b %f; echo; echo; mp3info -r a -x %f; id3info %f ) 2>&1 regex/\.(ogg|OGG|Ogg)$ - Open=if [ "$DISPLAY" = "" ]; then ogg123 %f; else (xmms %f &); fi + Open=if [ "$DISPLAY" = "" ]; then ogg123 %f; else (exec xmms %f &); fi View=%view{ascii} ogginfo %s regex/\.(midi?|MIDI?|Midi?|rmid?|RMID?|Rmid?)$ Open=timidity %f +regex/\.(wma|WMA|Wma)$ + Open=mplayer -vo null %f + View=%view{ascii} mplayer -quiet -slave -frames 0 -vo null -ao null -identify %f 2>/dev/null | tail +13 || file %f +### Play lists ### + +regex/\.([mM]3[uU]|[pP][lL][sS])$ + Open=if [ -z "$DISPLAY" ]; then mplayer -vo null -playlist %f; else (xmms -p %f &); fi + + ### Video ### +regex/\.([oO][gG][mM])$ + Include=video + regex/\.(avi|AVI|Avi)$ Include=video -regex/\.(asf|ASF|Asf)$ +regex/\.([aA][sS][fFxX])$ Include=video regex/\.(divx|DIVX|DivX|Divx)$ Include=video -regex/\.(mov|MOV|Mov)$ +regex/\.(mov|MOV|Mov|[qQ][tT])$ Include=video regex/\.(mp4|MP4|Mp4|mpe?g|MPE?G|Mpe?g)$ @@ -274,12 +287,12 @@ Include=video regex/\.(rm|RM|Rm|ram|RAM|Ram)$ - Open=(realplay %f >/dev/null 2>&1 &) + Open=(exec realplay %f >/dev/null 2>&1 &) include/video - Open=(mplayer %f >/dev/null 2>&1 &) - #Open=(gtv %f >/dev/null 2>&1 &) - #Open=(xanim %f >/dev/null 2>&1 &) + Open=(exec mplayer -slave %f >/dev/null 2>&1 &) + #Open=(exec gtv %f >/dev/null 2>&1 &) + #Open=(exec xine %f >/dev/null 2>&1 &) ### Documents ### @@ -360,7 +373,7 @@ Open=make -f %f %{Enter parameters} # Imakefile -shell/Imakefile +shell/Imakefile$ Open=xmkmf -a # Makefile.PL (MakeMaker) @@ -379,6 +392,11 @@ ### Archives ### +# .TGZ .TPZ .TAR.GZ .TAR.Z +regex/\.T([GP]Z|AR\.GZ)$ + Open=%cd %p#utar + View=%view{ascii} gzip -dc %f 2>/dev/null | tar tvvf - + # .tgz, .tpz, .tar.gz, .tar.z, .tar.Z regex/\.t([gp]?z|ar\.g?[zZ])$ Open=%cd %p#utar @@ -435,7 +453,7 @@ # rar regex/\.[rR]([aA][rR]|[0-9][0-9])$ Open=%cd %p#urar - View=%view{ascii} rar v -c- %f + View=%view{ascii} unrar v -c- %f # cpio shell/.cpio.Z @@ -497,12 +515,21 @@ # deb regex/\.deb$ Open=%cd %p#deb + #Open%cd %p#uar View=%view{ascii} dpkg-deb -c %f + #View=%vew{ascii} ar tv %f # ISO9660 regex/\.iso$ Open=%cd %p#iso9660 View=%view{ascii} isoinfo -l -i %f + + +### Misc ### + +# BitTorrent +regex/\.([tT][oO[rR][rR][eE][nN][tT])$ + View=%view{ascii} btshowmetainfo.py %f ### Default ### From roland.illig at gmx.de Sun Oct 10 18:12:10 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 10 Oct 2004 20:12:10 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <1097070876.4823.48.camel@athlon.localdomain> References: <200410060928.i969S9A6032842@email.zp.ua> <1097070876.4823.48.camel@athlon.localdomain> Message-ID: <41697B7A.7010702@gmx.de> Leonard den Ottolander wrote: > I believe Roland used pipethrough.c for a new version of the paste > output from external command in the editor. Exactly that. The function is currently unused. But it did compile fine with Linux 2.4, NetBSD 1.6.2, Solaris 2.9 and AIX 3.4. It can be removed for the current release. I have some plans for mc-4.6.2, which I have not published yet. In these plans the function pipethrough would be even more flexible, so I think the current version will not be used heavily. If anyone wants to delete it from CVS, feel free to do so. But don't forget to edit src/Makefile.am. Roland From eth0 at o2.pl Sun Oct 10 20:18:50 2004 From: eth0 at o2.pl (q#) Date: Sun, 10 Oct 2004 22:18:50 +0200 Subject: hash (sharp) in file and dir names over vfs.. In-Reply-To: <20041005141942.GA16841@hindus.hstl5.put.poznan.pl> References: <20041005141942.GA16841@hindus.hstl5.put.poznan.pl> Message-ID: <20041010201850.GA4231@hindus.hstl5.put.poznan.pl> On Tue, Oct 05, 2004 at 04:19:42PM +0200, q# wrote: > Hi, > > I've tested mc and found some problems with "#" in file and dir names > over vfs. My tests cover only sshfs (fish?), ftpfs, tarfs part of vfs. > > Fish has also problem with symlinks. I could not view symlink pointing > to regular file. Dir-links however works okay, but they are visible as > normal directories. > > I created some test archive, where you can see how problem looks like. > You can also unpack .tgz and browse it over sshfs and ftpfs for full > picture. > > My second issue are directories with spaces in prompt. For ex. when we > have "some dir" and in prompt we write 'rm -rf ' and press CTRL+ENTER, > result will be 'rm -rf some\ dir ', and execute it (ENTER) dir will > disapeare. That's ok. But when we write 'cd dome\ dir', built-in command > don't understand it properly, and mc shows 'no such file or...' > > Test file: > http://kubek.eu.org/~hns/pub/mc/mc-tests.tgz There is also problem with normal directories, when they have names like vfs-name, try create dir "test#utar" or "test#uar" in mc. I have update my above test archive. -- best regards q# From eth0 at o2.pl Sun Oct 10 22:12:39 2004 From: eth0 at o2.pl (q#) Date: Mon, 11 Oct 2004 00:12:39 +0200 Subject: mc with different colors Message-ID: <20041010221239.GA8223@hindus.hstl5.put.poznan.pl> Hi, I have write it many months ago, but found it today. This is simple script which launch mc with '-C' parameter, try new face of mc :) -- best regards q# -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-colors.sh Type: application/x-sh Size: 1814 bytes Desc: not available URL: From jnovy at redhat.com Mon Oct 11 09:58:22 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 11 Oct 2004 11:58:22 +0200 Subject: FTP password visibility fixes In-Reply-To: <1097322731.4788.7.camel@athlon.localdomain> References: <1097243275.22130.40.camel@localhost.localdomain> <1097322731.4788.7.camel@athlon.localdomain> Message-ID: <1097488702.3545.31.camel@localhost.localdomain> On Sat, 2004-10-09 at 13:52, Leonard den Ottolander wrote: > Could you please provide diff -up s and attach instead of inline? The > former for readability and the latter to avoid line wrapping problems > when extracting the patch. TIA. Ok, this patch should look a bit better. CVS version available this morning can be patched fine with it. -- 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: 10879 bytes Desc: not available URL: From andrew at email.zp.ua Mon Oct 11 12:42:54 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 11 Oct 2004 15:42:54 +0300 (EEST) Subject: Included S-Lang and configure Message-ID: <200410111242.i9BCgsXv036945@email.zp.ua> Hi, this patch has to fix system slang.h usage if mc is configured to use included slang. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcslang.patch URL: From me at pavelsh.pp.ru Tue Oct 12 12:59:46 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 12 Oct 2004 18:59:46 +0600 Subject: Included S-Lang and configure Included S-Lang and configure Included S-Lang and configure Re: Included S-Lang and configure Message-ID: <733860430.20041012185946@pavelsh.pp.ru> Hello, I committed fixes. Thanks Andrew. P.S.:It's my new mail address for mail-list. Previous don't recieve mail from gnome.org. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From jnovy at redhat.com Tue Oct 12 14:14:43 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 12 Oct 2004 16:14:43 +0200 Subject: mc SQL syntax patch Message-ID: <1097590483.4524.24.camel@localhost.localdomain> Hi, Karel Zak did a patch to improve sql.syntax file in mc and added several keywords. cheers, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-sql.patch Type: text/x-patch Size: 7098 bytes Desc: not available URL: From me at pavelsh.pp.ru Tue Oct 12 15:25:33 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 12 Oct 2004 21:25:33 +0600 Subject: mc SQL syntax patch In-Reply-To: <1097590483.4524.24.camel@localhost.localdomain> References: <1097590483.4524.24.camel@localhost.localdomain> Message-ID: <376463234.20041012212533@pavelsh.pp.ru> Hello Jindrich, Tuesday, October 12, 2004, 8:14:43 PM, you wrote: JN> Karel Zak did a patch to improve sql.syntax file in mc and added several JN> keywords. Committed. Thanks -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Tue Oct 12 18:12:38 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 12 Oct 2004 20:12:38 +0200 Subject: mc SQL syntax patch In-Reply-To: <1097590483.4524.24.camel@localhost.localdomain> References: <1097590483.4524.24.camel@localhost.localdomain> Message-ID: <1097604757.4786.67.camel@athlon.localdomain> Hi, On Tue, 2004-10-12 at 16:14, Jindrich Novy wrote: > Karel Zak did a patch to improve sql.syntax file in mc and added several > keywords. Yeah, I've something similar lying around. One question: - keyword whole CHAR_LENGTH yellow Is that keyword no longer valid in databases other than MySQL? More generally speaking, aren't some of the added keywords MySQL specific (tinyblob etc)? Maybe they should be added in a separate section instead of in the main section... Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Oct 14 12:36:46 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 14 Oct 2004 14:36:46 +0200 Subject: extfs shell scripts fixed patch In-Reply-To: <200410061036.i96AacqB035396@email.zp.ua> References: <200410061036.i96AacqB035396@email.zp.ua> Message-ID: <1097757405.4785.15.camel@athlon.localdomain> On Wed, 2004-10-06 at 12:36, Andrew V. Samoilov wrote: > audio.in fix does not cure $, " and ` in the filenames. Which code are you referring to specifically? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Oct 14 13:05:01 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 14 Oct 2004 15:05:01 +0200 Subject: extfs shell script fixes (audio.in) Message-ID: <1097759100.4785.45.camel@athlon.localdomain> Hi, Some remarks on the SUSE extfs shell fixes regarding audio.in: @@ -15,7 +15,7 @@ - cdparanoia -Q -d $1 2>&1 | grep '^[ 0-9][ 0-9][ 0-9]\.' | while true + cdparanoia -Q -d "$1" 2>&1 | grep '^[ 0-9][ 0-9][ 0-9]\.' | while true Quoting $1 is unnecessary here as no shell is spawned. This hunk can thus be dropped. Same is true for - cdparanoia -q -d $1 $TRACK $3 >/dev/null + cdparanoia -q -d "$1" $TRACK "$3" >/dev/null in @@ -28,15 +28,15 @@ @@ -48,7 +48,7 @@ - list) audiofs_list $BASE; exit 0;; - copyout) audiofs_copyout $BASE $3 $4; exit 0;; + list) audiofs_list "$BASE"; exit 0;; + copyout) audiofs_copyout "$BASE" "$3" "$4"; exit 0;; $BASE, $3 and $4 don't need to be quoted either. This makes me wonder if the quoting of $f and the use of SEDCMD in extfs/rpm mcrpmfs_copyout() and mcrpmfs_run aren't redundant either. Any thoughts? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Oct 14 13:21:11 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 14 Oct 2004 15:21:11 +0200 Subject: extfs shell script fixes (hp48.in) Message-ID: <1097760070.4785.56.camel@athlon.localdomain> Hi, Some remarks on the SUSE extfs shell fixes regarding hp48.in: Instead of using the CHECK loop it is probably just as easy to just quote the parameters that are being fed to spawned shells. See the attached patch (I don't distinguish between trusted and untrusted parameters, but just quote everything). Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: hp48.in.diff Type: text/x-patch Size: 1958 bytes Desc: not available URL: From andrew at email.zp.ua Fri Oct 15 16:36:29 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 15 Oct 2004 19:36:29 +0300 (EEST) Subject: Two patches for CVS Message-ID: <200410151636.i9FGaTP1005780@email.zp.ua> Hi, -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vfs-2004-10-15.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotlist.c.patch URL: From dmoisset at grulic.org.ar Fri Oct 15 18:09:57 2004 From: dmoisset at grulic.org.ar (Daniel F Moisset) Date: Fri, 15 Oct 2004 15:09:57 -0300 Subject: mcedit .syntax file for Eiffel Message-ID: <1097863796.15929.7.camel@dwarf.moisset> Hi, I'm attaching a syntax file to provide Eiffel syntax highlighting in mcedit. I've used it for a couple of years, and I thought it would be nice if it was included in mc Daniel -- Must it be assumed that because we are engineers beauty is not our concern, and that while we make our constructions robust and durable we do not also strive to make them elegant? Is it not true that the genuine conditions of strength always comply with the secret conditions of harmony? -- Gustave Eiffel, 1887 -------------- next part -------------- # Sytnax highlighting for Eiffel # Daniel F Moisset - dmoisset at grulic.org.ar # Based on mc's pascal.syntax context default yellow/24 keyword whole agent white/24 keyword whole alias white/24 keyword whole as white/24 keyword whole check white/24 keyword whole class white/24 keyword whole create white/24 keyword whole creation white/24 keyword whole debug white/24 keyword whole deferred white/24 keyword whole do white/24 keyword whole else white/24 keyword whole elseif white/24 keyword whole end white/24 keyword whole ensure white/24 keyword whole expanded white/24 keyword whole export white/24 keyword whole external white/24 keyword whole feature white/24 keyword whole from white/24 keyword whole if white/24 keyword whole is white/24 keyword whole indexing white/24 keyword whole inherit white/24 keyword whole inspect white/24 keyword whole invariant white/24 keyword whole like white/24 keyword whole local white/24 keyword whole loop white/24 keyword whole obsolete white/24 keyword whole old white/24 keyword whole once white/24 keyword whole redefine white/24 keyword whole reference white/24 keyword whole rename white/24 keyword whole require white/24 keyword whole rescue white/24 keyword whole retry white/24 keyword whole select white/24 keyword whole then white/24 keyword whole undefine white/24 keyword whole unique white/24 keyword whole until white/24 keyword whole variant white/24 keyword whole when white/24 keyword whole Current brightmagenta/23 keyword whole Precursor brightmagenta/23 keyword whole Result brightmagenta/23 keyword whole Void brightmagenta/23 # prevents - keyword from interfering with comment keyword -- lightgray/22 keyword := brightcyan/6 keyword ?= brightcyan/6 keyword ! brightcyan/6 keyword : brightcyan/6 keyword ; brightcyan/6 keyword ( brightcyan/6 keyword ) brightcyan/6 keyword [ brightcyan/6 keyword ] brightcyan/6 keyword {*} brightred/6 keyword \+ cyan/14 keyword - cyan/14 keyword \* cyan/14 keyword / cyan/14 keyword > cyan/14 keyword < cyan/14 keyword = cyan/14 keyword ^ cyan/14 keyword \\ cyan/14 keyword @ cyan/14 keyword | cyan/14 keyword whole and cyan/14 keyword whole implies cyan/14 keyword whole not cyan/14 keyword whole xor cyan/14 keyword whole or cyan/14 # Uncomment this to highlight tabs and trailing spaces # keyword \t yellow/24 red/6 # keyword \s\[\s\]\n yellow/24 red/6 # Comments context exclusive -- \n lightgray/22 keyword `*' brown/22 # Strings and characters context " " green/green keyword %N brightgreen/6 keyword %R brightgreen/6 keyword %U brightgreen/6 keyword %" brightgreen/6 keyword %' brightgreen/6 keyword %% brightgreen/6 keyword %/\[0123456789\]/ brightgreen/6 context ' ' green/green keyword %N brightgreen/6 keyword %R brightgreen/6 keyword %U brightgreen/6 keyword %" brightgreen/6 keyword %' brightgreen/6 keyword %% brightgreen/6 keyword %/\[0123456789\]/ brightgreen/6 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From leonard at den.ottolander.nl Sat Oct 16 11:19:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 16 Oct 2004 13:19:40 +0200 Subject: Two patches for CVS In-Reply-To: <200410151636.i9FGaTP1005780@email.zp.ua> References: <200410151636.i9FGaTP1005780@email.zp.ua> Message-ID: <1097925580.4816.5.camel@athlon.localdomain> Hi Andrew, On Fri, 2004-10-15 at 18:36, Andrew V. Samoilov wrote: > Hi, Wow. A short description might be nice ;) . Regarding vfs-2004-10-15.patch: So we don't need to abort if another error than EPIPE is returned? Regarding hotlist.c.patch: These fixes suggest title and url are (now?) duplicated in add2hotlist? Pavel, Roland, for every yes please commit :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 16 11:20:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 16 Oct 2004 13:20:50 +0200 Subject: extfs Message-ID: <1097925650.4816.8.camel@athlon.localdomain> Hey folks, Anybody care to comment on my previous posts on extfs? I want some answers before I fix those patches. TIA. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 16 11:29:31 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 16 Oct 2004 13:29:31 +0200 Subject: mcedit .syntax file for Eiffel In-Reply-To: <1097863796.15929.7.camel@dwarf.moisset> References: <1097863796.15929.7.camel@dwarf.moisset> Message-ID: <1097926171.4816.13.camel@athlon.localdomain> Hi Daniel, On Fri, 2004-10-15 at 20:09, Daniel F Moisset wrote: > I'm attaching a syntax file to provide Eiffel syntax highlighting in > mcedit. I've used it for a couple of years, and I thought it would be > nice if it was included in mc Sure, why not. Hardly any chance this will break anything :-) . Maybe we should do the same thing for occam (whatever that is?) (http://mail.gnome.org/archives/mc-devel/2004-July/msg00018.html). And PHP smarty? (http://mail.gnome.org/archives/mc-devel/2004-January/msg00068.html) Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Sat Oct 16 13:33:16 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 16 Oct 2004 15:33:16 +0200 Subject: mcedit .syntax file for Eiffel In-Reply-To: <1097926171.4816.13.camel@athlon.localdomain> References: <1097863796.15929.7.camel@dwarf.moisset> <1097926171.4816.13.camel@athlon.localdomain> Message-ID: <4171231C.7080103@gmx.de> Leonard den Ottolander wrote: > Sure, why not. Hardly any chance this will break anything :-) . :( The syntax parser wasn't able to handle "\r\n" linebreaks (=> SEGV). I have fixed that in current CVS. You may want to review the patch. It works for me. ;) Roland From roland.illig at gmx.de Sat Oct 16 16:19:22 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 16 Oct 2004 18:19:22 +0200 Subject: Once again (with new arguments): repository directory uncommitted-patches Message-ID: <41714A0A.3070703@gmx.de> Hi, I had some thoughts again about the "uncommitted-patches" directory that I had wished some times ago. I think I know now the main reason why I want to have it. It's a central read-write file store where someone from the project can leave a patch and someone else can later commit and delete it. The current practice is that everyone has his own website where he published patches. In most cases someone else will finally commit them. So the committer has to tell the patch's author that the patch can be deleted from the website. The new workflow would be: $Author adds a patch to the uncommitted-patches directory. $Reviewer applies the patch to his working copy and tests it. He can then commit the patch and delete it from the uncommitted-patches directory without having to tell $Author about it. ---- Please fill out ---- [ ] Pro: [ ] Con: ---- Roland From roland.illig at gmx.de Sat Oct 16 18:59:56 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 16 Oct 2004 20:59:56 +0200 Subject: find dialog Message-ID: <41716FAC.6090202@gmx.de> Hi, I just programmed the extended find dialog, as requested in the TODO for 4.6.2. Please try it. http://www.schlechte-software.de/pub/mc-patches/mc_src_find.c-plaintext-search.patch See http://www.schlechte-software.de/pub/mc-patches/ for my other creations. Roland From leonard at den.ottolander.nl Sun Oct 17 11:57:32 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 17 Oct 2004 13:57:32 +0200 Subject: Once again (with new arguments): repository directory uncommitted-patches In-Reply-To: <41714A0A.3070703@gmx.de> References: <41714A0A.3070703@gmx.de> Message-ID: <1098014252.4786.6.camel@athlon.localdomain> Hi Roland, On Sat, 2004-10-16 at 18:19, Roland Illig wrote: > I had some thoughts again about the "uncommitted-patches" directory that > I had wished some times ago. Do you want this directory to be part of the CVS tree, or do you want to maintain it separately? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Sun Oct 17 10:34:17 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Sun, 17 Oct 2004 12:34:17 +0200 Subject: Once again (with new arguments): repository directory uncommitted-patches In-Reply-To: <41714A0A.3070703@gmx.de> References: <41714A0A.3070703@gmx.de> Message-ID: Hello, On Sat, 16 Oct 2004, Roland Illig wrote: > I had some thoughts again about the "uncommitted-patches" directory that > I had wished some times ago. I think I know now the main reason why I > want to have it. It's a central read-write file store where someone from > the project can leave a patch and someone else can later commit and > delete it. What's wrong with the Savannah's patches repository from MC ? Sounds like the right place for me. From me at pavelsh.pp.ru Sun Oct 17 13:45:59 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Sun, 17 Oct 2004 19:45:59 +0600 Subject: Two patches for CVS In-Reply-To: <200410151636.i9FGaTP1005780@email.zp.ua> References: <200410151636.i9FGaTP1005780@email.zp.ua> Message-ID: <1096266941.20041017194559@pavelsh.pp.ru> Hello Andrew, Friday, October 15, 2004, 10:36:29 PM, you wrote: Committed. Thx. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From siver at sirius.ihep.su Sun Oct 17 14:14:37 2004 From: siver at sirius.ihep.su (Siver Andrey) Date: Sun, 17 Oct 2004 18:14:37 +0400 Subject: Interchange with X Clipboard Message-ID: <002b01c4b453$b376f760$f3a1bec2@hermes> Hi All, I've opened for myself interesting program: http://www.opennet.ru/xfilesel/ May be is it possible to insert it into MC project? Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Sun Oct 17 15:25:25 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 17 Oct 2004 17:25:25 +0200 Subject: Once again (with new arguments): repository directory uncommitted-patches In-Reply-To: References: <41714A0A.3070703@gmx.de> Message-ID: <41728EE5.3050800@gmx.de> Pavel Tsekov wrote: > Hello, > > On Sat, 16 Oct 2004, Roland Illig wrote: > > >>I had some thoughts again about the "uncommitted-patches" directory that >>I had wished some times ago. I think I know now the main reason why I >>want to have it. It's a central read-write file store where someone from >>the project can leave a patch and someone else can later commit and >>delete it. > > > What's wrong with the Savannah's patches repository from MC ? Sounds like > the right place for me. I cannot delete (even my own) patches from the patches repository, but I could delete them if they were in CVS. (So it's just a question of who gets write access to what section of Savannah.) I also like the idea that we have everything in one place (the CVS) using the same access method (CVS). Roland From roland.illig at gmx.de Sun Oct 17 15:27:19 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 17 Oct 2004 17:27:19 +0200 Subject: Once again (with new arguments): repository directory uncommitted-patches In-Reply-To: <1098014252.4786.6.camel@athlon.localdomain> References: <41714A0A.3070703@gmx.de> <1098014252.4786.6.camel@athlon.localdomain> Message-ID: <41728F57.8030705@gmx.de> Leonard den Ottolander wrote: > Hi Roland, > > On Sat, 2004-10-16 at 18:19, Roland Illig wrote: > >>I had some thoughts again about the "uncommitted-patches" directory that >>I had wished some times ago. > > > Do you want this directory to be part of the CVS tree, or do you want to > maintain it separately? The directory structure I thought of was: +-- CVSROOT +-- mc `-- uncommitted-patches So the patches would not affect the current working tree. Roland From leonard at den.ottolander.nl Sun Oct 17 17:57:05 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 17 Oct 2004 19:57:05 +0200 Subject: extfs shell script fixes (audio.in) In-Reply-To: <1097759100.4785.45.camel@athlon.localdomain> References: <1097759100.4785.45.camel@athlon.localdomain> Message-ID: <1098035825.4800.8.camel@athlon.localdomain> Hi, I wrote: > Quoting $1 is unnecessary here as no shell is spawned. This hunk can > thus be dropped. As Roland pointed out to me although the quoting is not necessary from a security standpoint it saves special characters and spaces. Reintroduced. See attached patch. > This makes me wonder if the quoting of $f and the use of SEDCMD in > extfs/rpm mcrpmfs_copyout() and mcrpmfs_run aren't redundant either. ... Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: audio.in.diff Type: text/x-patch Size: 1661 bytes Desc: not available URL: From roland.illig at gmx.de Sun Oct 17 18:42:46 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 17 Oct 2004 20:42:46 +0200 Subject: vfs/smbfs.c (1.86) Message-ID: <4172BD26.2060906@gmx.de> Hi, > if (ret <= 0) { > if (errno == EPIPE) > return False; > } else > nwritten += ret; > } I think we should also exit the loop if errno != EPIPE, as the current version might introduce an endless loop. Roland From leonard at den.ottolander.nl Sun Oct 17 18:58:42 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 17 Oct 2004 20:58:42 +0200 Subject: extfs shell script fixes (hp48.in) In-Reply-To: <1097760070.4785.56.camel@athlon.localdomain> References: <1097760070.4785.56.camel@athlon.localdomain> Message-ID: <1098039522.4800.13.camel@athlon.localdomain> Hi, I wrote: > Instead of using the CHECK loop it is probably just as easy to just > quote the parameters that are being fed to spawned shells. 'nother try. See attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: hp48.in.diff Type: text/x-patch Size: 2642 bytes Desc: not available URL: From roland.illig at gmx.de Sun Oct 17 19:37:27 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 17 Oct 2004 21:37:27 +0200 Subject: extfs shell script fixes (hp48.in) In-Reply-To: <1098039522.4800.13.camel@athlon.localdomain> References: <1097760070.4785.56.camel@athlon.localdomain> <1098039522.4800.13.camel@athlon.localdomain> Message-ID: <4172C9F7.4080905@gmx.de> Leonard den Ottolander wrote: > Hi, > > I wrote: > >>Instead of using the CHECK loop it is probably just as easy to just >>quote the parameters that are being fed to spawned shells. > > > 'nother try. See attached patch. > > Leonard. Committed. Roland From buliabyak at gmail.com Sun Oct 17 19:39:54 2004 From: buliabyak at gmail.com (bulia byak) Date: Sun, 17 Oct 2004 16:39:54 -0300 Subject: Interchange with X Clipboard In-Reply-To: <002b01c4b453$b376f760$f3a1bec2@hermes> References: <002b01c4b453$b376f760$f3a1bec2@hermes> Message-ID: <3c78ff030410171239756ecdc3@mail.gmail.com> > I've opened for myself interesting program: http://www.opennet.ru/xfilesel/ > > May be is it possible to insert it into MC project? I use this one: http://people.debian.org/~kims/xclip/ My patched mc uses it for copying the path of the selected file to clipboard on Ctrl+C (can hardly imagine how I would live without that!). I will submit this patch when I have more spare time. I don't know if xfilesel is better. Unfortunately xclip has some bugs and is not maintained anymore. I think it's more powerful, so I would prefer that someone fix and update xclip. From roland.illig at gmx.de Sun Oct 17 19:45:08 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 17 Oct 2004 21:45:08 +0200 Subject: extfs shell script fixes (audio.in) In-Reply-To: <1098035825.4800.8.camel@athlon.localdomain> References: <1097759100.4785.45.camel@athlon.localdomain> <1098035825.4800.8.camel@athlon.localdomain> Message-ID: <4172CBC4.2030608@gmx.de> Leonard den Ottolander wrote: > --- vfs/extfs/audio.in.orig 2003-08-09 00:07:16.000000000 +0200 > +++ vfs/extfs/audio.in 2004-09-29 11:10:51.000000000 +0200 Committed. Roland From eth0 at o2.pl Mon Oct 18 00:27:37 2004 From: eth0 at o2.pl (q#) Date: Mon, 18 Oct 2004 02:27:37 +0200 Subject: extfs audio.in & hp48.in patch Message-ID: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> Hi, I modify little those two files. Command `echo "test test"` is not the same as "`echo "test test"`", so I add those additional `"'. Small test shows: mkdir "$HOME/dir with spaces" cd `basename "$HOME/dir with spaces"` /bin/sh: cd: too many arguments Second point is, that in hp48.in there is $*, but parrent function execute it with "", that means there will be only one argv -- "$1". With "$1" is easier to see the picture. My practice with /bin/sh scripts is that the best solution with functions that have many arguments is using "$@", with this you don't lost special characters like spaces, etc. ps. I hope that some one understand me :/ this is word-mess :\ -- best regards q# -------------- next part -------------- Index: vfs/extfs/audio.in =================================================================== RCS file: /cvsroot/mc/mc/vfs/extfs/audio.in,v retrieving revision 1.7 diff -u -r1.7 audio.in --- vfs/extfs/audio.in 17 Oct 2004 19:42:20 -0000 1.7 +++ vfs/extfs/audio.in 18 Oct 2004 00:08:48 -0000 @@ -12,7 +12,7 @@ CDDB_HANDSHAKE="hello=user+localhost+mc+1.0&proto=1" CDDB_TIMEOUT=20 # in seconds -audiofs_list () +audiofs_list() { DATE=`date +"%b %d %H:%M"` echo "-r--r--r-- 1 0 0 0 $DATE CDDB" @@ -24,7 +24,7 @@ done } -audiofs_copyout () +audiofs_copyout() { if [ "$2" == "CDDB" ]; then DISCID=`cd-discid "$1" | tr " " "+"` @@ -32,7 +32,7 @@ exit 1 fi RESPONSE=`wget -q -T $CDDB_TIMEOUT -O - "$CDDB_SERVER/~cddb/cddb.cgi?cmd=cddb+query+$DISCID&$CDDB_HANDSHAKE" | tee "$3" | @AWK@ '/^200/ { print $2,$3; }'` - wget -q -T $CDDB_TIMEOUT -O - "$CDDB_SERVER/~cddb/cddb.cgi?cmd=cddb+read+$RESPONSE&$CDDB_HANDSHAKE" | grep -v "^#" >> $3 + wget -q -T $CDDB_TIMEOUT -O - "$CDDB_SERVER/~cddb/cddb.cgi?cmd=cddb+read+$RESPONSE&$CDDB_HANDSHAKE" | grep -v "^#" >> "$3" else TRACK=`echo "$2" | sed 's/track-0*//' | sed 's/\.wav//'` cdparanoia -q -d "$1" $TRACK "$3" >/dev/null @@ -43,7 +43,7 @@ then BASE=/dev/cdrom else - BASE=$2 + BASE="$2" fi case "$1" in Index: vfs/extfs/hp48.in =================================================================== RCS file: /cvsroot/mc/mc/vfs/extfs/hp48.in,v retrieving revision 1.2 diff -u -r1.2 hp48.in --- vfs/extfs/hp48.in 17 Oct 2004 19:33:55 -0000 1.2 +++ vfs/extfs/hp48.in 18 Oct 2004 00:08:48 -0000 @@ -26,13 +26,13 @@ hp48_cmd() { -$KERMIT -C "SET EXIT WARNING OFF,REMOTE $*,QUIT" +$KERMIT -C "SET EXIT WARNING OFF,REMOTE $@,QUIT" } hp48_cd() { (echo SET EXIT WARNING OFF;echo REMOTE HOST HOME -for HP48_DIR in `echo "$*" | tr '/' ' '`;do +for HP48_DIR in `echo "$1" | tr '/' ' '`;do if [ "x$HP48_DIR" != "x." ];then echo REMOTE HOST "$HP48_DIR"; fi done echo QUIT)| $KERMIT -B >/dev/null @@ -79,20 +79,20 @@ LC_ALL=C export LC_ALL -case $1 in +case "$1" in list) HP48_CDIR= hp48_cmd HOST HOME >/dev/null hp48_list exit 0;; copyout) - cd `dirname "$4"` - hp48_cd `dirname "$3"` - $KERMIT -B -g `basename "$3"` -a "$4" >/dev/null + cd "`dirname "$4"`" + hp48_cd "`dirname "$3"`" + $KERMIT -B -g "`basename "$3"`" -a "$4" >/dev/null exit 0;; copyin) - cd `dirname "$4"` - hp48_cd `dirname "$3"` - $KERMIT -B -s "$4" -a `basename "$3"` >/dev/null + cd "`dirname "$4"`" + hp48_cd "`dirname "$3"`" + $KERMIT -B -s "$4" -a "`basename "$3"`" >/dev/null exit 0;; esac exit 1 From roland.illig at gmx.de Mon Oct 18 02:05:43 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 18 Oct 2004 04:05:43 +0200 Subject: using the SLang library politely Message-ID: <417324F7.7030606@gmx.de> Hi, I think we should replace the calls to _SLsys_getkey() and _SLsys_input_pending with calls to SLang_getkey() and SLang_input_pending. (see src/slint.c.) The latter functions are from the public interface of SLang, the former ones are internal system-dependent functions. The SLang_* functions are wrappers around the _SLsys_* functions. As we are _using_ the SLang library we should stick to the public interface. The functions starting with an underscore are -- as usual -- internal to the package (and used for _implementing_ it), so we should treat it as such. Roland From roland.illig at gmx.de Mon Oct 18 02:23:39 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 18 Oct 2004 04:23:39 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> Message-ID: <4173292B.2020703@gmx.de> q# wrote: > My practice with /bin/sh scripts is that the best solution with > functions that have many arguments is using "$@", with this you don't > lost special characters like spaces, etc. You're right. It's a much better solution. > @@ -43,7 +43,7 @@ > then > BASE=/dev/cdrom > else > - BASE=$2 > + BASE="$2" > fi This is not strictly necessary, but I left it in. I even enclosed the "/dev/cdrom" in quotes. (It's a string. Strings are enclosed in quotes.) Patch committed. Thanks. Roland From ossi at kde.org Mon Oct 18 05:57:44 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Mon, 18 Oct 2004 07:57:44 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> Message-ID: <20041018055744.GA2919@ugly.local> On Mon, Oct 18, 2004 at 02:27:37AM +0200, q# wrote: > - BASE=$2 > + BASE="$2" > pointless > -$KERMIT -C "SET EXIT WARNING OFF,REMOTE $*,QUIT" > +$KERMIT -C "SET EXIT WARNING OFF,REMOTE $@,QUIT" > counter-productive: # set -- one two three # for i in "you $@ suck"; do echo $i; done you one two three suck # i think the behaviour isn't even specified. > -case $1 in > +case "$1" in > pointless i suggest you read and internalize a [posix] shell documentation (ash/dash seems like a good candidate) before starting to fix shell scripts. btw, the autoconf manual gives a good overview of shell incompatibilites - for those of you who think one can't overdo quoting. -- 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 Mon Oct 18 10:00:02 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 18 Oct 2004 12:00:02 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <20041018055744.GA2919@ugly.local> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <20041018055744.GA2919@ugly.local> Message-ID: <1098093601.4811.0.camel@athlon.localdomain> Hello Oswald, On Mon, 2004-10-18 at 07:57, Oswald Buddenhagen wrote: > # for i in "you $@ suck"; do echo $i; done You choose your examples carefully I see >:-/ Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Oct 18 10:05:21 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 18 Oct 2004 12:05:21 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <4173292B.2020703@gmx.de> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <4173292B.2020703@gmx.de> Message-ID: <1098093920.4811.7.camel@athlon.localdomain> Hello Roland, On Mon, 2004-10-18 at 04:23, Roland Illig wrote: > Patch committed. Thanks. What happened to the patch I submitted? Did you commit that as well? I seem to be missing some quoting in the patch from q#. Could we please come to a common understanding on the issues before committing loads of different hunks please? This is messy. Is it so hard to wait just a few hours more? Come on! TIA. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Oct 18 10:08:56 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 18 Oct 2004 12:08:56 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <1098093920.4811.7.camel@athlon.localdomain> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <4173292B.2020703@gmx.de> <1098093920.4811.7.camel@athlon.localdomain> Message-ID: <1098094135.4811.11.camel@athlon.localdomain> Hello Roland, On Mon, 2004-10-18 at 12:05, I wrote: > What happened to the patch I submitted? Sorry. It seems you became a victim of my filter rules. I should have been checking my inbox first. > Could we please come to a common understanding on the issues before > committing loads of different hunks please? But this criticism still stands. The patches I submitted were a proposal which could have been improved before being committed. Ah well, maybe I should just have another cup of coffee first. Cheers, Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Mon Oct 18 10:19:22 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 18 Oct 2004 12:19:22 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <20041018055744.GA2919@ugly.local> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <20041018055744.GA2919@ugly.local> Message-ID: <417398AA.60802@gmx.de> Oswald Buddenhagen wrote: >>-$KERMIT -C "SET EXIT WARNING OFF,REMOTE $*,QUIT" >>+$KERMIT -C "SET EXIT WARNING OFF,REMOTE $@,QUIT" > > counter-productive: > > # set -- one two three > # for i in "you $@ suck"; do echo $i; done > you one > two > three suck > # Yes, you're right. Thanks for pointing this out. I have changed this to $KERMIT -C "SET EXIT WARNING OFF,REMOTE $1,QUIT" and quoted the places where hp48_cmd is called. I think this is easier to understand. (And I don't like $*.) [Offtopic:] Can you tell me a situation where you use $*? > i suggest you read and internalize a [posix] shell documentation (ash/dash > seems like a good candidate) before starting to fix shell scripts. btw, > the autoconf manual gives a good overview of shell incompatibilites - > for those of you who think one can't overdo quoting. Well, I think that it is not easy to do overquoting the wrong way. The approach that I like is to quote everything that I consider to be a string. This includes arguments to `case'. Roland From roland.illig at gmx.de Mon Oct 18 10:34:01 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 18 Oct 2004 12:34:01 +0200 Subject: Proposal for HACKING.sh.txt Message-ID: <41739C19.9040604@gmx.de> Hi, I think we could collect some wisdom of how to properly write shell scripts. This is my first draft: Writing Portable and Secure Shell Scripts ======================================================================== 1. Shell Quoting Generally, enclose all variables and strings in double quotes. Pay attention to backticks, dollar signs and backslashes, as they are interpreted in double quotes. One exception could be assignments a=$b, where no quoting is necessary. But for uniformity of the code I suggest we write a="$b" in this case, too. In the assignment a=`command` I would prefer not to quote the command. 2. Quoting File Names File names that start with a special character [^A-Za-z0-9_./] might be interpreted as command line option by shell commands. Therefore file names should be quoted using the mc_shellquote function: # example: qfname=`mc_shellquote "$fname"` mc_shellquote() { case "$1" in [A-Za-z0-9_./]*) echo "$1";; *) echo "./$1";; esac } ======================================================================== Roland From roland.illig at gmx.de Mon Oct 18 10:38:57 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 18 Oct 2004 12:38:57 +0200 Subject: Proposal for HACKING.sh.txt In-Reply-To: <41739C19.9040604@gmx.de> References: <41739C19.9040604@gmx.de> Message-ID: <41739D41.6090006@gmx.de> Roland Illig wrote: > Hi, > > I think we could collect some wisdom of how to properly write shell > scripts. This is my first draft: > > Writing Portable and Secure Shell Scripts > ======================================================================== 0. Read the Autotools manual http://sources.redhat.com/autobook/autobook/autobook_208.html > 1. Shell Quoting > [...] Roland From leonard at den.ottolander.nl Mon Oct 18 15:59:10 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 18 Oct 2004 17:59:10 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> Message-ID: <1098115150.4811.27.camel@athlon.localdomain> Hello Roland, On Mon, 2004-10-18 at 02:27, q# wrote: > hp48_cd() > { > (echo SET EXIT WARNING OFF;echo REMOTE HOST HOME > -for HP48_DIR in `echo "$*" | tr '/' ' '`;do > +for HP48_DIR in `echo "$1" | tr '/' ' '`;do As I said: Please discuss before committing. In two steps this part has now totally been ruined. Maybe the quoting in this place was wrong. My mistake. But I didn't ask you to commit, only to review. Now $* has changed from "$*" into "$1" which is definitely *not* what is supposed to be. Look folks. Many of us do not speak English very well. This will cause misunderstandings that can be avoided if patches are not committed blindly. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Mon Oct 18 16:25:22 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 18 Oct 2004 18:25:22 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <1098115150.4811.27.camel@athlon.localdomain> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <1098115150.4811.27.camel@athlon.localdomain> Message-ID: <4173EE72.2060903@gmx.de> Leonard den Ottolander wrote: > Hello Roland, > > On Mon, 2004-10-18 at 02:27, q# wrote: > >> hp48_cd() >> { >> (echo SET EXIT WARNING OFF;echo REMOTE HOST HOME >>-for HP48_DIR in `echo "$*" | tr '/' ' '`;do >>+for HP48_DIR in `echo "$1" | tr '/' ' '`;do > > > As I said: Please discuss before committing. In two steps this part has > now totally been ruined. It's like a d?j? vu. I'll take a committing break. > Maybe the quoting in this place was wrong. My mistake. But I didn't ask > you to commit, only to review. Now $* has changed from "$*" into "$1" > which is definitely *not* what is supposed to be. *sigh* I don't like my behaviour. :( But I think that the new version works. Everywhere the function hp48_cd() is called, it gets exactly one argument. This argument is splitted into path components, and as the `echo ...` is not enclosed in quotes, it expands to 0..n words. Roland From leonard at den.ottolander.nl Mon Oct 18 16:25:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 18 Oct 2004 18:25:40 +0200 Subject: Free VFSs now Message-ID: <1098116740.4811.30.camel@athlon.localdomain> Hi, Where has the option Free VFSs now gone? I miss this when testing vfs scripts. When not freeing an opened VFS first I cannot see changes with the script. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Oct 18 16:37:58 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 18 Oct 2004 18:37:58 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <4173EE72.2060903@gmx.de> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <1098115150.4811.27.camel@athlon.localdomain> <4173EE72.2060903@gmx.de> Message-ID: <1098117477.4811.41.camel@athlon.localdomain> Hi Roland, On Mon, 2004-10-18 at 18:25, Roland Illig wrote: > It's like a d?j? vu. I'll take a committing break. No need to take a break, just be more careful reviewing before committing. All I'm trying to point out is that we might want to come to a common understanding before committing. If we build on each others patches and send those back to the list it shouldn't take too long before everybody is happy and all the work can be committed in a single go. This will avoid the Changelog growing unnecessarily large. The first part in this breakage was obviously my mistake as I introduced the quoting here. But then I only proposed for review, not as a final patch. Maybe I should make that more clear next time (the difference between "probably good" and "definitely good"). Anyway, the only thing affected seems to be the '$*' that changed into a '"$1"'. But since this '$*' is part of the arguments to a for in loop I assume we want to parse more than just one variable, and thus '"$1"' should be reverted to '$*'. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From eth0 at o2.pl Mon Oct 18 17:29:35 2004 From: eth0 at o2.pl (q#) Date: Mon, 18 Oct 2004 19:29:35 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <1098117477.4811.41.camel@athlon.localdomain> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <1098115150.4811.27.camel@athlon.localdomain> <4173EE72.2060903@gmx.de> <1098117477.4811.41.camel@athlon.localdomain> Message-ID: <20041018172935.GA10804@hindus.hstl5.put.poznan.pl> On Mon, Oct 18, 2004 at 06:37:58PM +0200, Leonard den Ottolander wrote: > Anyway, the only thing affected seems to be the '$*' that changed into a > '"$1"'. But since this '$*' is part of the arguments to a for in loop I > assume we want to parse more than just one variable, and thus '"$1"' > should be reverted to '$*'. But hp48_cd() functions gas only one argument, it will be more clearly with "$1". `for' loop is using spaces created by tr '/' ' ', and loop is working. -- best regards q# From roland.illig at gmx.de Mon Oct 18 18:07:59 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 18 Oct 2004 20:07:59 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <20041018172935.GA10804@hindus.hstl5.put.poznan.pl> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <1098115150.4811.27.camel@athlon.localdomain> <4173EE72.2060903@gmx.de> <1098117477.4811.41.camel@athlon.localdomain> <20041018172935.GA10804@hindus.hstl5.put.poznan.pl> Message-ID: <4174067F.50806@gmx.de> q# wrote: > But hp48_cd() functions gas only one argument, it will be more clearly > with "$1". `for' loop is using spaces created by tr '/' ' ', and loop is > working. That's my opinion, too. Roland From leonard at den.ottolander.nl Mon Oct 18 18:43:47 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 18 Oct 2004 20:43:47 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <20041018172935.GA10804@hindus.hstl5.put.poznan.pl> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <1098115150.4811.27.camel@athlon.localdomain> <4173EE72.2060903@gmx.de> <1098117477.4811.41.camel@athlon.localdomain> <20041018172935.GA10804@hindus.hstl5.put.poznan.pl> Message-ID: <1098125027.4811.44.camel@athlon.localdomain> Hello q#, On Mon, 2004-10-18 at 19:29, q# wrote: > But hp48_cd() functions gas only one argument, it will be more clearly > with "$1". `for' loop is using spaces created by tr '/' ' ', and loop is > working. Yup. I didn't read your post well enough. Roland explained this to me on Freenode #mc-devel. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ossi at kde.org Mon Oct 18 19:00:04 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Mon, 18 Oct 2004 21:00:04 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <417398AA.60802@gmx.de> <1098093601.4811.0.camel@athlon.localdomain> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <20041018055744.GA2919@ugly.local> <417398AA.60802@gmx.de> <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <20041018055744.GA2919@ugly.local> <1098093601.4811.0.camel@athlon.localdomain> Message-ID: <20041018190004.GC2919@ugly.local> On Mon, Oct 18, 2004 at 12:19:22PM +0200, Roland Illig wrote: > [Offtopic:] Can you tell me a situation where you use $*? > i have a few scripts that i just pass a text that might be unquoted as the last argument(s). in this case echo-ing $* makes sense. nothing i'd suggest to somebody who doesn't know the quoting rules in and out ... > >btw, the autoconf manual gives a good overview of shell > >incompatibilites - for those of you who think one can't overdo > >quoting. > > Well, I think that it is not easy to do overquoting the wrong way. > it can't be wrong per se as long as it is correct, obviously. but problems arise with certain shells getting confused by deeper quoting constructs. > The approach that I like is to quote everything that I consider to be > a string. This includes arguments to `case'. > otoh, more quotes means more chars to parse, making the code harder to read for those who _do_ know the rules asleep. :) ------ On Mon, Oct 18, 2004 at 12:00:02PM +0200, Leonard den Ottolander wrote: > On Mon, 2004-10-18 at 07:57, Oswald Buddenhagen wrote: > > # for i in "you $@ suck"; do echo $i; done > > You choose your examples carefully I see >:-/ > yeah. :-)=) well, actually, i only wanted to test it for myself and nothing better came to my mind while i stared at the screen of my computer called ugly (i'm weird, huh? :). later i decided to post it and was too lazy to change it. :) -- 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 Mon Oct 18 22:29:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 00:29:50 +0200 Subject: extfs audio.in & hp48.in patch In-Reply-To: <20041018190004.GC2919@ugly.local> References: <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <20041018055744.GA2919@ugly.local> <417398AA.60802@gmx.de> <20041018002736.GA27622@hindus.hstl5.put.poznan.pl> <20041018055744.GA2919@ugly.local> <1098093601.4811.0.camel@athlon.localdomain> <20041018190004.GC2919@ugly.local> Message-ID: <1098138590.4811.51.camel@athlon.localdomain> Hello Oz, On Mon, 2004-10-18 at 21:00, Oswald Buddenhagen wrote: > well, actually, i only wanted to test it for myself and nothing better > came to my mind while i stared at the screen of my computer called ugly > (i'm weird, huh? :). later i decided to post it and was too lazy to > change it. :) Just consider that people might read things in this that you didn't mean to say. It's hard enough to get across a message correctly with spoken language + facial expressions & body language, let alone in an email. But as you point out no offense was intended so I hope none was taken :) Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Tue Oct 19 07:17:30 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Tue, 19 Oct 2004 10:17:30 +0300 (EEST) Subject: Two patches for CVS In-Reply-To: <1097925580.4816.5.camel@athlon.localdomain> Message-ID: <200410190717.i9J7HUoC044894@email.zp.ua> Hi Leonard, > Regarding vfs-2004-10-15.patch: So we don't need to abort if another > error than EPIPE is returned? Well, I read write_socket() and I need to say this is good catch. > Regarding hotlist.c.patch: These fixes suggest title and url are > (now?) duplicated in add2hotlist? No, but quick_dialog() g_strdup()s string value(s). -- Regards, Andrew V. Samoilov. From leonard at den.ottolander.nl Tue Oct 19 10:41:00 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 12:41:00 +0200 Subject: small patches Message-ID: <1098182460.4811.45.camel@athlon.localdomain> Hi, Taken from Fedora's latest srpm. Looks like these still need to be applied. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-smallpatches.patch Type: text/x-patch Size: 763 bytes Desc: not available URL: From leonard at den.ottolander.nl Tue Oct 19 10:56:05 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 12:56:05 +0200 Subject: Two patches for CVS In-Reply-To: <200410190717.i9J7HUoC044894@email.zp.ua> References: <200410190717.i9J7HUoC044894@email.zp.ua> Message-ID: <1098183364.4811.61.camel@athlon.localdomain> Hi Andrew, On Tue, 2004-10-19 at 09:17, Andrew V. Samoilov wrote: > > Regarding vfs-2004-10-15.patch: So we don't need to abort if another > > error than EPIPE is returned? > > Well, I read write_socket() and I need to say this is good catch. So are you going to submit another version or should this just be reverted? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Oct 19 11:42:21 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 13:42:21 +0200 Subject: LGPL using GPL code Message-ID: <1098186140.4811.71.camel@athlon.localdomain> Hi, Although we haven't had an answer on Andrew Samoilov's request to Jindrich Novy from Red Hat whether LGPL code can use GPL functions -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Oct 19 11:54:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 13:54:40 +0200 Subject: LGPL using GPL code In-Reply-To: <1098186140.4811.71.camel@athlon.localdomain> References: <1098186140.4811.71.camel@athlon.localdomain> Message-ID: <1098186880.4811.73.camel@athlon.localdomain> Hi, I wrote: > Although we haven't had an answer on Andrew Samoilov's request to > Jindrich Novy from Red Hat whether LGPL code can use GPL functions Oops. I wonder where this message went. It wasn't supposed to be sent yet :) Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Oct 19 13:38:03 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 15:38:03 +0200 Subject: Two patches for CVS In-Reply-To: <200410191258.i9JCwuDM057836@email.zp.ua> References: <200410191258.i9JCwuDM057836@email.zp.ua> Message-ID: <1098193083.4811.116.camel@athlon.localdomain> Hello Andrew, On Tue, 2004-10-19 at 14:58, Andrew V. Samoilov wrote: > There were 2 bugs before this patch, and now we have 1 ;-) > I will submit another version some later. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Oct 19 16:58:04 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 18:58:04 +0200 Subject: LGPL code using GPL code Message-ID: <1098205084.4811.129.camel@athlon.localdomain> 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? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Oct 19 17:36:09 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 19:36:09 +0200 Subject: dependency problem installing MC in Redhat 9.0 In-Reply-To: <4171C903.6000503@virtual-orbis.com> References: <4171C903.6000503@virtual-orbis.com> Message-ID: <1098207368.4811.138.camel@athlon.localdomain> Hi Alejandro, On Sun, 2004-10-17 at 03:21, Alejandro Lengua - Virtual Orbis wrote: > I am having a hard time trying to install midnight commander > (mc-4.6.0-2.i386.rpm), actually my only dependency left is > libslang.so.1 .... Why are you complicating your life? Red Hat Linux 9.0 comes with an mc rpm as well as the correct slang version. Don't use --nodeps if you don't know what you are doing. And where does that rpm come from? If you want to upgrade mc on RHL 9.0 you should start out with the existing srpm and adjust that. Most of the patches from that srpm can be dropped if you work with CVS as they are committed. You might want to preserve the utf8 patch. Even easier is to wait until tomorrow and get the latest srpm for Fedora Core 3 (test 3), which will be featuring fixes to the utf8 patches. rpmbuild --rebuild mc-4.6.1-.src.rpm on RHL 9.0 should render a perfectly usable rpm. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Tue Oct 19 17:49:10 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Tue, 19 Oct 2004 20:49:10 +0300 (EEST) Subject: LGPL code using GPL code In-Reply-To: <1098205084.4811.129.camel@athlon.localdomain> Message-ID: <200410191749.i9JHnAaJ068315@email.zp.ua> Hi, Leonard > 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. -- Regards, Andrew V. Samoilov. From leonard at den.ottolander.nl Tue Oct 19 18:11:00 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 19 Oct 2004 20:11:00 +0200 Subject: LGPL code using GPL code In-Reply-To: <200410191749.i9JHnAaJ068315@email.zp.ua> References: <200410191749.i9JHnAaJ068315@email.zp.ua> Message-ID: <1098209459.4811.149.camel@athlon.localdomain> Hello Andrew, On Tue, 2004-10-19 at 19:49, Andrew V. Samoilov wrote: > License may change back to GPL if all the VFS authors agree ;-( > I think it will take a long time. No. The problem only exists in the other direction. You can't make the license less restrictive, but you can make it more restrictive. So you can distribute copies of LGPLed code under the GPL. Out of courtesy it is a good idea to release a tarball before the license change, but there is nothing stopping us from relicensing LGPL code as GPL. See http://www.fsf.org/licenses/lgpl.html , paragraph 3: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Tue Oct 19 22:19:15 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 20 Oct 2004 00:19:15 +0200 Subject: LGPL code using GPL code In-Reply-To: <1098205084.4811.129.camel@athlon.localdomain> References: <1098205084.4811.129.camel@athlon.localdomain> Message-ID: <417592E3.7050407@gmx.de> Leonard den Ottolander wrote: > 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? Perhaps never. The mcvfs code has been understood as being a library that is an integral part of the Midnight Commander, but should also be able to live on its own. According to vfs/README, instead of changing the license it would be better to write the necessary functions as part of mcvfs. See vfs/README for details. Currently there are 595 undefined references when trying to link libvfs-mc.a with a simple main.c file. When linking together with the GLib-1.2, there are still 182 undefined references to 31 distinct symbols. Sorted and uniqued they are: canonicalize_pathname cd_symlinks close_error_pipe concat_dir_and_file current_panel decompress_extension disable_interrupt_key enable_interrupt_key exist_file get_compression_type get_current_type get_other_panel get_other_type got_interrupt g_strlcpy home_dir input_dialog load_anon_passwd load_file mc_home mc_mkstemps message my_system name_quote open_error_pipe print_vfs_message shell shell_execute skip_separators unix_error_string wipe_password Some of these functions have nothing to do with implementing a vfs. What does a vfs need to know about the current_panel and the other_panel? The input_dialog is just one form of user interaction. So the function calling input_dialog should better use a callback mechanism instead of having the name hardcoded. As a challenge we could try to minimize the number of functions the mcvfs really needs. And of the ones that it really needs, we should decide which ones should be part of the public interface of the library (vfs/vfs.h) or the implementor's interface (vfs/vfs-impl.h). I vote for this challenge because we can exercise how to design clean interfaces between the Midnight Commander and its vfs. I consider clean interfaces an essential part of every software package. Roland From leonard at den.ottolander.nl Tue Oct 19 22:44:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 00:44:50 +0200 Subject: extfs trpm Message-ID: <1098225889.4811.159.camel@athlon.localdomain> Hi, Attached you find the proposed fixes to trpm. The SEDCMD that is used in rpm can not be used for the rpms file system. This should fix all the quoting. Increased the "file" size for UNINSTALL to 40 as the message "uninstalling rpm" was missing the last char. Please check for omissions and errors before committing ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Oct 19 22:47:31 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 00:47:31 +0200 Subject: extfs trpm In-Reply-To: <1098225889.4811.159.camel@athlon.localdomain> References: <1098225889.4811.159.camel@athlon.localdomain> Message-ID: <1098226050.4811.163.camel@athlon.localdomain> On Wed, 2004-10-20 at 00:44, Leonard den Ottolander wrote: > Hi, > > Attached you find the proposed fixes to trpm. The SEDCMD that is used in > rpm can not be used for the rpms file system. This should fix all the > quoting. Increased the "file" size for UNINSTALL to 40 as the message > "uninstalling rpm" was missing the last char. > > Please check for omissions and errors before committing ;) . Always handy to actually attach the patch :-) . Here it is. > Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: trpm.diff Type: text/x-patch Size: 10260 bytes Desc: not available URL: From eth0 at o2.pl Wed Oct 20 01:32:41 2004 From: eth0 at o2.pl (q#) Date: Wed, 20 Oct 2004 03:32:41 +0200 Subject: simple patch for lib/mc.ext.in In-Reply-To: <20041010164417.GA28530@hindus.hstl5.put.poznan.pl> References: <20041010164417.GA28530@hindus.hstl5.put.poznan.pl> Message-ID: <20041020013241.GC17735@hindus.hstl5.put.poznan.pl> On Sun, Oct 10, 2004 at 06:44:17PM +0200, q# wrote: > Hi, > > It adds: > * view images with identify || file > * tar archive with uppercase > * bittorrent files view > * playlist files (with xmms or mplayer) > * .WMA audio files (with mplayer) > * .ogm video (with mplayer) > * .qt video (with mplayer) > * minor stuff Can some one review this patch, maybe multimedia stuff is unnecessary but I think that identify || file is worth commint. This also switch rar to unrar with F3 view, I think that unrar is mutch common because sources are awaliable and more OSes could use it. Patch: http://kubek.eu.org/~hns/pub/mc/ -- best regards q# From me at pavelsh.pp.ru Wed Oct 20 05:14:30 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 20 Oct 2004 11:14:30 +0600 Subject: simple patch for lib/mc.ext.in In-Reply-To: <20041020013241.GC17735@hindus.hstl5.put.poznan.pl> References: <20041010164417.GA28530@hindus.hstl5.put.poznan.pl> <20041020013241.GC17735@hindus.hstl5.put.poznan.pl> Message-ID: <1911873917.20041020111430@pavelsh.pp.ru> Hello q#, Wednesday, October 20, 2004, 7:32:41 AM, you wrote: q> On Sun, Oct 10, 2004 at 06:44:17PM +0200, q# wrote: >> Hi, >> >> It adds: >> * view images with identify || file >> * tar archive with uppercase >> * bittorrent files view >> * playlist files (with xmms or mplayer) >> * .WMA audio files (with mplayer) >> * .ogm video (with mplayer) >> * .qt video (with mplayer) >> * minor stuff q> Can some one review this patch, maybe multimedia stuff is unnecessary q> but I think that identify || file is worth commint. This also switch rar q> to unrar with F3 view, I think that unrar is mutch common because q> sources are awaliable and more OSes could use it. q> Patch: q> http://kubek.eu.org/~hns/pub/mc/ Partially committed. Thx. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From ptsekov at gmx.net Wed Oct 20 05:56:43 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 20 Oct 2004 07:56:43 +0200 Subject: small patches In-Reply-To: <1098182460.4811.45.camel@athlon.localdomain> References: <1098182460.4811.45.camel@athlon.localdomain> Message-ID: Hi, On Tue, 19 Oct 2004, Leonard den Ottolander wrote: > Taken from Fedora's latest srpm. Looks like these still need to be > applied. It isn't obvious (at least for me) what this patch does - seems like it is just an optimization (sparing a call to test_line). Is that true, or is it some kind of a bugfix. A changelog entry would be fine. From jnovy at redhat.com Wed Oct 20 08:24:32 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 20 Oct 2004 10:24:32 +0200 Subject: LGPL code using GPL code In-Reply-To: <1098205084.4811.129.camel@athlon.localdomain> References: <1098205084.4811.129.camel@athlon.localdomain> Message-ID: <1098260672.15180.26.camel@localhost.localdomain> Hi, On Tue, 2004-10-19 at 18:58, Leonard den Ottolander wrote: > 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 well, I delayed a bit with the answer because I have discussed this issue on our os-development mailing list and was gathering information. my question was: > In mc we have VFS code that is licensed under LGPL. This code is using > code from another directory where it is licensed under GPL. Isn't it a > legal problem? Is it ok? and some of replies I had: Arjan van de Ven: it's explicitly allowed, but it means the LGPL code is used as GPL code at that point, eg basically the "L" goes away... ;) Roland McGrath: There is no problem unless you are producing a library containing some GPL source code and then distributing a library binary and claiming that it is under the LGPL. So in my opinion there's not a big problem in this since we are not distributing any mc library claiming it is LGPL. For the license conversion to GPL please note, that you need all the authors of mc to agree with it. I hope it helped a bit, but note I'm a programmer, not a lawyer ;-) cheers, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From leonard at den.ottolander.nl Wed Oct 20 11:29:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 13:29:25 +0200 Subject: LGPL code using GPL code In-Reply-To: <1098260672.15180.26.camel@localhost.localdomain> References: <1098205084.4811.129.camel@athlon.localdomain> <1098260672.15180.26.camel@localhost.localdomain> Message-ID: <1098271765.4813.11.camel@athlon.localdomain> Hello Jindrich, On Wed, 2004-10-20 at 10:24, Jindrich Novy wrote: > Arjan van de Ven: > it's explicitly allowed, but it means the LGPL code is used as GPL code > at that point, eg basically the "L" goes away... ;) > > Roland McGrath: > There is no problem unless you are producing a library containing some > GPL source code and then distributing a library binary and claiming that > it is under the LGPL. > > So in my opinion there's not a big problem in this since we are not > distributing any mc library claiming it is LGPL. Just what I thought, but this makes the vfs parts undistributable as a separate entity under the LGPL as they use GPL code. > For the license > conversion to GPL please note, that you need all the authors of mc to > agree with it. No! I said this before. The LGPL specifically allows redistribution under the GPL. See paragraph 3 that I quoted in my mail. E.g. you can make the license stricter, but people can still use the "original" code as LGPL. So there are 4 possibilities (3 1/2 actually): 1) We ask the authors of the GPLed functions if we can redistribute the involved functions in src as LGPL. This will make the vfs redistributable as a separate entity under the LGPL. 2) We rewrite all "offending" functions. I don't think this is a very good idea. I think Roland is overestimating the use of inappropriate functions in the vfs code. Sure, some can go, but the bulk can not. 3) We brand all LGPLed vfs code as GPL, because vfs isn't redistributable as LGPL in it's current implementation anyway. 4) We leave the licenses as are, and put in the README that vfs although LGPLed is not redistributable as a separate entity under the LGPL in it's current implementation because it uses GPLed code. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Oct 20 11:42:44 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 13:42:44 +0200 Subject: simple patch for lib/mc.ext.in In-Reply-To: <1911873917.20041020111430@pavelsh.pp.ru> References: <20041010164417.GA28530@hindus.hstl5.put.poznan.pl> <20041020013241.GC17735@hindus.hstl5.put.poznan.pl> <1911873917.20041020111430@pavelsh.pp.ru> Message-ID: <1098272564.4813.22.camel@athlon.localdomain> Hi Pavel, On Wed, 2004-10-20 at 07:14, Pavel Shirshov (pchel) wrote: > Wednesday, October 20, 2004, 7:32:41 AM, you wrote: > q> Can some one review this patch, maybe multimedia stuff is unnecessary > q> but I think that identify || file is worth commint. > Partially committed. Thx. Could you specify what you committed and what not? And why? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Oct 20 11:49:32 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 13:49:32 +0200 Subject: small patches In-Reply-To: References: <1098182460.4811.45.camel@athlon.localdomain> Message-ID: <1098272971.4813.31.camel@athlon.localdomain> Hello Pavel, On Wed, 2004-10-20 at 07:56, Pavel Tsekov wrote: > It isn't obvious (at least for me) what this patch does - seems like it > is just an optimization (sparing a call to test_line). Is that true, or is > it some kind of a bugfix. A changelog entry would be fine. I seldomly doubt patches coming from Jakub :) . This is how Jakub explained it to Pavel Shirshov: > You want to skip over += resp. =+. > test_line handles + and = the same, but doesn't DTRT when it sees two > of them adjacent. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Oct 20 12:13:41 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 14:13:41 +0200 Subject: [patch] vfs/README Message-ID: <1098274420.4813.34.camel@athlon.localdomain> Hi, To get this issue of my mind I've added a word of warning to vfs/README telling people vfs can currently not be redistributed under the LGPL as a whole package. See attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: README.diff Type: text/x-patch Size: 436 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Oct 20 12:18:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 14:18:50 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <200410051446.i95Ekp7P000900@email.zp.ua> References: <200410051446.i95Ekp7P000900@email.zp.ua> Message-ID: <1098274730.4813.39.camel@athlon.localdomain> Hello Andrew, On Tue, 2004-10-05 at 16:46, Andrew V. Samoilov wrote: > Edit dot.cpio and replace abc with ./b. Tap into dot.cpio. > I think this will be definitely understand that tar.c is wrong place to fix > this issue. The cpio binary does not save the ./ in ./file if you feed it such arguments. Your example is thus an artifact that should not normally occur. Please compare this (taken from the TODO): " - In file.c, we shouldn't need to get a full path name in order to work, we should instead canon the file name inside the tar.c (the only fs that relies on this), tar.c should know about the cwd (i think). " Or is this remark unrelated to this issue? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Wed Oct 20 12:30:23 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 20 Oct 2004 18:30:23 +0600 Subject: small patches In-Reply-To: <1098182460.4811.45.camel@athlon.localdomain> References: <1098182460.4811.45.camel@athlon.localdomain> Message-ID: <1918802403.20041020183023@pavelsh.pp.ru> Hello Leonard, Tuesday, October 19, 2004, 4:41:00 PM, you wrote: LdO> Taken from Fedora's latest srpm. Looks like these still need to be LdO> applied. Committed. Thx. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Wed Oct 20 18:51:55 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 20:51:55 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <415C47F2.9010102@gmx.de> References: <415C47F2.9010102@gmx.de> Message-ID: <1098298314.4901.67.camel@athlon.localdomain> Hi Roland, On Thu, 2004-09-30 at 19:52, Roland Illig wrote: > this patch fixes the second TODO item for 4.6.1. I wasn't aware of the fact that this patch had been committed as I thought we were still discussing where this issue should be fixed. If we stay with this fix, does the attached patch make any sense? The q++ is just geekness, but I'm wondering if the canonicalize_pathname is actually useful here, or counterproductive, as we are indirectly working on current_file_name. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: tar.c.diff Type: text/x-patch Size: 514 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Oct 20 19:16:19 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 20 Oct 2004 21:16:19 +0200 Subject: LGPL code using GPL code In-Reply-To: <417592E3.7050407@gmx.de> References: <1098205084.4811.129.camel@athlon.localdomain> <417592E3.7050407@gmx.de> Message-ID: <1098299778.4901.92.camel@athlon.localdomain> Hello Roland, On Wed, 2004-10-20 at 00:19, Roland Illig wrote: > The mcvfs code has been understood as being a library that is an > integral part of the Midnight Commander, but should also be able to live > on its own. Yes, but not as LGPLed code with it's current dependency on quite af few GPLed functions. It might have been a nice idea to implement vfs as a separable library way back, but it is not of much practical value right now. > According to vfs/README, instead of changing the license it would be > better to write the necessary functions as part of mcvfs. That is quite a lot of work. I've done some more analysis based on your list of used symbols. All of the files below, except for glibcompat.c which is licensed LGPL, are licensed under the GPL. That means all of the below functions except g_strlcpy would need to be rewritten for vfs to live as a separate LGPLed entity. src/execute.c: shell_execute src/glibcompat.c: g_strlcpy src/layout.c: get_current_type get_other_panel get_other_type print_vfs_message src/main.c: cd_symlinks home_dir (home_dir = getenv ("HOME")) mc_home shell (shell = "/bin/sh") src/panel.c: current_panel src/setup.c: load_anon_passwd src/slint.c: disable_interrupt_key enable_interrupt_key got_interrupt src/util.c: concat_dir_and_file decompress_extension exist_file get_compression_type load_file mc_mkstemps name_quote skip_separators unix_error_string wipe_password src/utilunix.c: canonicalize_pathname close_error_pipe my_system open_error_pipe src/wtools.c: input_dialog message > Some of these functions have nothing to do with implementing a vfs. A few yes, but most of the above functions are rather general purpose. Rewriting all of them will be quite a lot of redundant work. > I vote for this challenge because we can exercise how to design clean > interfaces between the Midnight Commander and its vfs. Nothing wrong with cleaning up the vfs code, but I don't think it's a good idea to rewrite all of the above functions. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From miguel at ximian.com Wed Oct 20 19:27:08 2004 From: miguel at ximian.com (Miguel de Icaza) Date: Wed, 20 Oct 2004 15:27:08 -0400 Subject: LGPL code using GPL code In-Reply-To: <1098299778.4901.92.camel@athlon.localdomain> References: <1098205084.4811.129.camel@athlon.localdomain> <417592E3.7050407@gmx.de> <1098299778.4901.92.camel@athlon.localdomain> Message-ID: <1098300428.7484.262.camel@linux.site> Hello, > That is quite a lot of work. I've done some more analysis based on your > list of used symbols. All of the files below, except for glibcompat.c > which is licensed LGPL, are licensed under the GPL. That means all of > the below functions except g_strlcpy would need to be rewritten for vfs > to live as a separate LGPLed entity. For any code that I wrote (you might check the CVS logs) I can grant relicensing rights to the code under the LGPL. > src/execute.c: > shell_execute I dont remember that one. > src/layout.c: > get_current_type > get_other_panel > get_other_type > print_vfs_message I wrote those. > src/main.c: > cd_symlinks > home_dir (home_dir = getenv ("HOME")) > mc_home > shell (shell = "/bin/sh") free to relicense. > src/panel.c: > current_panel free to relicense. > src/setup.c: > load_anon_passwd free to relicense. > src/slint.c: > disable_interrupt_key > enable_interrupt_key > got_interrupt I believe I implemented those. > src/util.c: > concat_dir_and_file ditto. > decompress_extension Jakub most likely did this and a few others. > exist_file > get_compression_type > load_file > mc_mkstemps > name_quote > skip_separators > unix_error_string > wipe_password Did these two or four. > src/utilunix.c: > canonicalize_pathname ditto (maybe Jakub and Radek also). > close_error_pipe > my_system > open_error_pipe Janne might have been the author of these (my_system I believe everyone touched). > src/wtools.c: > input_dialog > message Radek wrote the original code, I rewrote it completely, so it might be ok, except if people modified after. For the record, I dont object to move any of my contributions from GPL to LGPL if it serves the team's effort. Miguel From roland.illig at gmx.de Wed Oct 20 19:43:34 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 20 Oct 2004 21:43:34 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <1098298314.4901.67.camel@athlon.localdomain> References: <415C47F2.9010102@gmx.de> <1098298314.4901.67.camel@athlon.localdomain> Message-ID: <4176BFE6.3030006@gmx.de> Leonard den Ottolander wrote: > q = current_file_name; > - /* FIXME: should be q = vfs_normalize_dir(q) */ > while (q[0] == '.' && q[1] == '/') > q += 2; > if (*q == '.' && *(q+1) == '\0') > - q = ""; > + q++; Well, that's hard to decide. ;) I just discovered that some lines above the same idiom (str += strlen(str)) is used. The fine points of the semantic are: >>> q++ <<< We actually have (and it is important that it is) a pointer to the pathname. >>> q = "" <<< q will be assigned an empty string. Personally, I prefer the second one, as we don't care to which empty string q points. > + canonicalize_pathname(q); The function canonicalize_pathname is not suited to the problem. We should split it into two functions: 1. canonicalize_pathname_but_preserve_UNC() 2. canonicalize_unix_pathname Then we can use canonicalize_unix_pathname to do the job. As UNC pathnames have nothing to do with Unix I wonder how the function has found its way into util*unix*.c. Roland From roland.illig at gmx.de Thu Oct 21 19:01:20 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 21 Oct 2004 21:01:20 +0200 Subject: Lingering patches In-Reply-To: <1096917378.4777.79.camel@athlon.localdomain> References: <1096806988.4751.2.camel@athlon.localdomain> <1096809947.4751.12.camel@athlon.localdomain> <015f01c4aa41$480b1ae0$98e7b8d9@ingrid> <1096917378.4777.79.camel@athlon.localdomain> Message-ID: <41780780.2010400@gmx.de> Leonard den Ottolander wrote: > Hi Roland, > > On Mon, 2004-10-04 at 20:35, Roland Illig wrote: > >>I had problems with src/regex.c, because it first #defines _GNU_SOURCE and >>then #includes , which makes gcc (and maybe others) choke about >>the duplicate definition. > > >>#include >>#ifndef _GNU_SOURCE >>#define _GNU_SOURCE 1 >>#endif > > > src/regex.c is the only occurrence I can find. Is the 1 in the above > example necessary? Doesn't the #define suffice (assuming we have the > AC_DEFINE in configure.ac)? Compare Jakub's mc-CVS-vcsa patch I > mentioned in this same thread. Actually, some files in the intl/ subdirectory also #define _GNU_SOURCE. Roland From roland.illig at gmx.de Thu Oct 21 19:53:09 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 21 Oct 2004 21:53:09 +0200 Subject: mc-4.6.1 release? Message-ID: <417813A5.80202@gmx.de> Hi, I would like mc-4.6.1 to be released soon. The broken pipe issue won't get away in the next few days, so there's no reason to wait for it. I have a still uncommitted patch which fixes the error message to be not as cryptic as before. http://www.schlechte-software.de/pub/mc-patches/mcview-sigpipe.patch After the release I would like to have an "unstable" branch where I (and everyone else) may put his favourite patches. From there we can commit the patches to the "stable" branch as soon as they are considered stable. I think this will speed up development and make it more clear which patches have already been applied and which ones still have to be checked. But I don't dare to suggest this before the release of mc-4.6.1. ;) Roland From proski at gnu.org Thu Oct 21 22:01:28 2004 From: proski at gnu.org (Pavel Roskin) Date: Thu, 21 Oct 2004 18:01:28 -0400 (EDT) Subject: mc-4.6.1 release? In-Reply-To: <417813A5.80202@gmx.de> References: <417813A5.80202@gmx.de> Message-ID: On Thu, 21 Oct 2004, Roland Illig wrote: > I would like mc-4.6.1 to be released soon. The broken pipe issue won't get > away in the next few days, so there's no reason to wait for it. I have a > still uncommitted patch which fixes the error message to be not as cryptic as > before. > > http://www.schlechte-software.de/pub/mc-patches/mcview-sigpipe.patch It's unfortunate because it will be perceived as a regression, even though the code in 4.6.0 was incorrect. > After the release I would like to have an "unstable" branch where I (and > everyone else) may put his favourite patches. From there we can commit the > patches to the "stable" branch as soon as they are considered stable. I think > this will speed up development and make it more clear which patches have > already been applied and which ones still have to be checked. But I don't > dare to suggest this before the release of mc-4.6.1. ;) OK, we need some testing before the release. maint/mctest gives some warnings on Fedora Core 2. From test-2.err: ../../vfs/mcserv.c: In function `mc_pam_auth': ../../vfs/mcserv.c:782: warning: assignment discards qualifiers from pointer target type ../../vfs/mcserv.c:783: warning: assignment discards qualifiers from pointer target type ../../src/cons.saver.c:52: warning: no previous prototype for `send_contents' ../../src/cons.saver.c:105: warning: no previous prototype for `die' We also should test FreeBSD and Cygwin. -- Regards, Pavel Roskin From roland.illig at gmx.de Thu Oct 21 23:08:54 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 22 Oct 2004 01:08:54 +0200 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> Message-ID: <41784186.8040703@gmx.de> Pavel Roskin wrote: > On Thu, 21 Oct 2004, Roland Illig wrote: > >> I would like mc-4.6.1 to be released soon. The broken pipe issue won't >> get away in the next few days, so there's no reason to wait for it. I >> have a still uncommitted patch which fixes the error message to be not >> as cryptic as before. >> >> http://www.schlechte-software.de/pub/mc-patches/mcview-sigpipe.patch > > It's unfortunate because it will be perceived as a regression, even > though the code in 4.6.0 was incorrect. I know. The problem is our usage of open_error_pipe() and close_error_pipe(), which is bad by design. (It will run into a deadlock if the child process writes more than a few kbytes to stderr; stderr writes directly on the screen in the "paste output of" editor command.) There will be an alternative soon. I am already working on it. > OK, we need some testing before the release. maint/mctest gives some > warnings on Fedora Core 2. From test-2.err: > > ../../vfs/mcserv.c: In function `mc_pam_auth': > ../../vfs/mcserv.c:782: warning: assignment discards qualifiers from > pointer target type > ../../vfs/mcserv.c:783: warning: assignment discards qualifiers from > pointer target type > ../../src/cons.saver.c:52: warning: no previous prototype for > `send_contents' > ../../src/cons.saver.c:105: warning: no previous prototype for `die' I have fixed them. The changes were trivial. The warnings had been there because I don't HAVE_PAM and so I didn't notice them. > We also should test FreeBSD and Cygwin. I have just collected the 28 build logs of my test configurations on SPARC/SunOS-5.9. They all failed because INADDR_NONE is not #defined. I have committed patches for these, too and will rerun the testsuite. Roland From roland.illig at gmx.de Thu Oct 21 23:15:50 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 22 Oct 2004 01:15:50 +0200 Subject: mc on SunOS Message-ID: <41784326.5090500@gmx.de> Hi, any complaints about this patch? Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: mc_src_utilunix.c-solaris.patch Type: text/x-patch Size: 1081 bytes Desc: not available URL: From eth0 at o2.pl Fri Oct 22 02:12:42 2004 From: eth0 at o2.pl (q#) Date: Fri, 22 Oct 2004 04:12:42 +0200 Subject: mc-4.6.1 release? In-Reply-To: <41784186.8040703@gmx.de> References: <417813A5.80202@gmx.de> <41784186.8040703@gmx.de> Message-ID: <20041022021242.GA6713@hindus.hstl5.put.poznan.pl> On Fri, Oct 22, 2004 at 01:08:54AM +0200, Roland Illig wrote: > >We also should test FreeBSD and Cygwin. > > I have just collected the 28 build logs of my test configurations on > SPARC/SunOS-5.9. They all failed because INADDR_NONE is not #defined. I > have committed patches for these, too and will rerun the testsuite. I've compiled mc-2004-10-20-16 at my OpenBSD box, it works for me, if you want to look at build logs you can find them here[1]. If someone want adidtional info about build environment please contact me. [1] http://kubek.eu.org/~hns/pub/mc/build-log/ -- best regards q# From me at pavelsh.pp.ru Fri Oct 22 05:47:17 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Fri, 22 Oct 2004 11:47:17 +0600 Subject: mc-4.6.1 release? In-Reply-To: <417813A5.80202@gmx.de> References: <417813A5.80202@gmx.de> Message-ID: <1189522547.20041022114717@pavelsh.pp.ru> Hello Roland, Friday, October 22, 2004, 1:53:09 AM, you wrote: RI> I would like mc-4.6.1 to be released soon. Please check. http://pavelsh.pp.ru/wiki/doku.php?id=mc-bugs -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Fri Oct 22 06:31:25 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Fri, 22 Oct 2004 12:31:25 +0600 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> Message-ID: <1503850123.20041022123125@pavelsh.pp.ru> Hello Pavel, Friday, October 22, 2004, 4:01:28 AM, you wrote: PR> We also should test FreeBSD and Cygwin. On FreeBSD5.2.1 box. ================================================================= regex.c:57:23: warning: "HAVE_WCTYPE_H" is not defined regex.c:95:7: warning: "HAVE_LIBINTL_H" is not defined In file included from regex.c:637: regex.c:2085:7: warning: "__BOUNDED_POINTERS__" is not defined regex.c:2242:24: warning: "HAVE_WCTYPE_H" is not defined regex.c:3295:23: warning: "HAVE_WCTYPE_H" is not defined regex.c:4552:6: warning: "_LIBC" is not defined regex.c:4570:6: warning: "_LIBC" is not defined ================================================================= mc from cvs working fine on FreeBSD5.2.1. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From roland.illig at gmx.de Fri Oct 22 06:51:25 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 22 Oct 2004 08:51:25 +0200 Subject: mc-4.6.1 release? In-Reply-To: <1189522547.20041022114717@pavelsh.pp.ru> References: <417813A5.80202@gmx.de> <1189522547.20041022114717@pavelsh.pp.ru> Message-ID: <4178ADED.8080506@gmx.de> Pavel Shirshov (pchel) wrote: > Hello Roland, > > Friday, October 22, 2004, 1:53:09 AM, you wrote: > > RI> I would like mc-4.6.1 to be released soon. > > Please check. > http://pavelsh.pp.ru/wiki/doku.php?id=mc-bugs This page is great. Why didn't you add it to the "Bugs and Patches" section in ./HACKING so we all know about it? Roland From roland.illig at gmx.de Fri Oct 22 07:11:33 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 22 Oct 2004 09:11:33 +0200 Subject: mc-4.6.1 release? In-Reply-To: <1189522547.20041022114717@pavelsh.pp.ru> References: <417813A5.80202@gmx.de> <1189522547.20041022114717@pavelsh.pp.ru> Message-ID: <4178B2A5.3070809@gmx.de> Pavel Shirshov (pchel) wrote: > Hello Roland, > > Friday, October 22, 2004, 1:53:09 AM, you wrote: > > RI> I would like mc-4.6.1 to be released soon. > > Please check. > http://pavelsh.pp.ru/wiki/doku.php?id=mc-bugs I fixed the "bug with linux /proc" entry. http://www.schlechte-software.de/pub/mc-patches/mc_src_view.c-hexview-growing.patch Please choose: [ ] ok, you may commit [ ] let me some time to review [ ] rejected Roland From roland.illig at gmx.de Fri Oct 22 07:54:33 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 22 Oct 2004 09:54:33 +0200 Subject: mc-4.6.1 release? In-Reply-To: <1503850123.20041022123125@pavelsh.pp.ru> References: <417813A5.80202@gmx.de> <1503850123.20041022123125@pavelsh.pp.ru> Message-ID: <4178BCB9.9080602@gmx.de> Pavel Shirshov (pchel) wrote: > Hello Pavel, > > Friday, October 22, 2004, 4:01:28 AM, you wrote: > > PR> We also should test FreeBSD and Cygwin. > > > On FreeBSD5.2.1 box. > ================================================================= > regex.c:57:23: warning: "HAVE_WCTYPE_H" is not defined > regex.c:95:7: warning: "HAVE_LIBINTL_H" is not defined > In file included from regex.c:637: > regex.c:2085:7: warning: "__BOUNDED_POINTERS__" is not defined > regex.c:2242:24: warning: "HAVE_WCTYPE_H" is not defined > regex.c:3295:23: warning: "HAVE_WCTYPE_H" is not defined > regex.c:4552:6: warning: "_LIBC" is not defined > regex.c:4570:6: warning: "_LIBC" is not defined > ================================================================= Yeah, that's the GNU style of using the C preprocessor: #if HAVE_WCTYPE_H which may expand to #if The better way is to query #if defined(HAVE_WCTYPE_H) && HAVE_WCTYPE_H I have changed that, checked manually for typos and compiled it. So it should work without putting it on review first. Roland From jakub at redhat.com Fri Oct 22 08:13:37 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 22 Oct 2004 10:13:37 +0200 Subject: mc-4.6.1 release? In-Reply-To: <4178BCB9.9080602@gmx.de> References: <417813A5.80202@gmx.de> <1503850123.20041022123125@pavelsh.pp.ru> <4178BCB9.9080602@gmx.de> Message-ID: <20041022081337.GH30497@sunsite.ms.mff.cuni.cz> On Fri, Oct 22, 2004 at 09:54:33AM +0200, Roland Illig wrote: > Pavel Shirshov (pchel) wrote: > >Hello Pavel, > > > >Friday, October 22, 2004, 4:01:28 AM, you wrote: > > > >PR> We also should test FreeBSD and Cygwin. > > > > > >On FreeBSD5.2.1 box. > >================================================================= > >regex.c:57:23: warning: "HAVE_WCTYPE_H" is not defined > >regex.c:95:7: warning: "HAVE_LIBINTL_H" is not defined > >In file included from regex.c:637: > >regex.c:2085:7: warning: "__BOUNDED_POINTERS__" is not defined > >regex.c:2242:24: warning: "HAVE_WCTYPE_H" is not defined > >regex.c:3295:23: warning: "HAVE_WCTYPE_H" is not defined > >regex.c:4552:6: warning: "_LIBC" is not defined > >regex.c:4570:6: warning: "_LIBC" is not defined > >================================================================= > > Yeah, that's the GNU style of using the C preprocessor: > > #if HAVE_WCTYPE_H I don't see what is GNU style on it. ISO C99, 6.10.1 says: ... After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers are replaced with the pp-number 0, and then each preprocessing token is converted into a token. ... Thus, the above should be handled like #if 0 if HAVE_WCTYPE_H is not defined. Jakub From roland.illig at gmx.de Fri Oct 22 09:30:25 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 22 Oct 2004 11:30:25 +0200 Subject: mc-4.6.1 release? In-Reply-To: <20041022081337.GH30497@sunsite.ms.mff.cuni.cz> References: <417813A5.80202@gmx.de> <1503850123.20041022123125@pavelsh.pp.ru> <4178BCB9.9080602@gmx.de> <20041022081337.GH30497@sunsite.ms.mff.cuni.cz> Message-ID: <4178D331.4030807@gmx.de> Jakub Jelinek wrote: > I don't see what is GNU style on it. > ISO C99, 6.10.1 says: > ... > After all replacements due to macro expansion and the defined unary operator > have been performed, all remaining identifiers are replaced with the > pp-number 0, and then each preprocessing token is converted into a token. > ... Oh, I haven't seen that before. Interesting. But nevertheless gcc warns about using #if with an undefined symbol. Roland From jakub at redhat.com Fri Oct 22 09:40:56 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 22 Oct 2004 05:40:56 -0400 Subject: mc-4.6.1 release? In-Reply-To: <4178D331.4030807@gmx.de> References: <417813A5.80202@gmx.de> <1503850123.20041022123125@pavelsh.pp.ru> <4178BCB9.9080602@gmx.de> <20041022081337.GH30497@sunsite.ms.mff.cuni.cz> <4178D331.4030807@gmx.de> Message-ID: <20041022094056.GL31909@devserv.devel.redhat.com> On Fri, Oct 22, 2004 at 11:30:25AM +0200, Roland Illig wrote: > Jakub Jelinek wrote: > >I don't see what is GNU style on it. > >ISO C99, 6.10.1 says: > >... > >After all replacements due to macro expansion and the defined unary > >operator > >have been performed, all remaining identifiers are replaced with the > >pp-number 0, and then each preprocessing token is converted into a token. > >... > > Oh, I haven't seen that before. Interesting. But nevertheless gcc warns > about using #if with an undefined symbol. Only if -Wundef is explicitely specified (-Wundef is not included in -Wall nor -W, nor even e.g. -pedantic -std=c89 warns about it). There are many warnings that are issued even for conforming code if people commonly make errors in it. Jakub From roland.illig at gmx.de Fri Oct 22 12:58:09 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 22 Oct 2004 14:58:09 +0200 Subject: patchfs: Fixed leading ./ bug Message-ID: <417903E1.1010208@gmx.de> Hi, with this patch patchfs accepts file names that are "equivalent" to the ones mentioned in the patch file. [ ] ok to commit [ ] needs review [ ] rejected Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: vfs_extfs_patchfs.in-leading-dot.patch Type: text/x-patch Size: 1179 bytes Desc: not available URL: From roland.illig at gmx.de Fri Oct 22 13:21:05 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 22 Oct 2004 15:21:05 +0200 Subject: patch: mcview with growing buffers Message-ID: <41790941.3030200@gmx.de> Hi, this patch is quite complex. It fixes these issues: - WView contained a struct stat that was only partly used (and mostly abused for _not_ storing file information). - Error checking using the growing buffer has been added. - Some variables need an adjustment function called after they are assigned a new value. This is explicitly documented. - Some variables have been renamed. For example, char *data is now accompanied by size_t datasize. A similar change has been applied to the mmap functions: The variable bytes_read has been used inconsistently and has been replaced by mmappedsize. - The function get_byte has become much simpler after factoring out the growing buffer handling into a separate function. Please fill out: [ ] ok to commit [ ] needs review [ ] rejected Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: mc_src_view.c-error-handling.patch Type: text/x-patch Size: 13420 bytes Desc: not available URL: From ptsekov at gmx.net Fri Oct 22 12:34:41 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 22 Oct 2004 14:34:41 +0200 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> Message-ID: Hello, On Thu, 21 Oct 2004, Pavel Roskin wrote: > We also should test FreeBSD and Cygwin. Attached is the patch to fix the following warning: ../../src/complete.c:222: warning: redundant redeclaration of `environ' in same scope /usr/include/sys/unistd.h:15: warning: previous declaration of `environ' Cygwin declares `environ' in unistd.h as per SUS. -------------- next part -------------- Index: complete.c =================================================================== RCS file: /cvsroot/mc/mc/src/complete.c,v retrieving revision 1.51 diff -u -p -r1.51 complete.c --- complete.c 27 Sep 2004 11:26:53 -0000 1.51 +++ complete.c 22 Oct 2004 14:29:32 -0000 @@ -218,7 +218,7 @@ username_completion_function (char *text } /* Linux declares environ in , so don't repeat it here. */ -#if (!(defined(__linux__) && defined (__USE_GNU))) +#if (!(defined(__linux__) && defined (__USE_GNU)) && !defined(__CYGWIN__)) extern char **environ; #endif From ptsekov at gmx.net Fri Oct 22 15:39:34 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 22 Oct 2004 17:39:34 +0200 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> Message-ID: Hello, On Thu, 21 Oct 2004, Pavel Roskin wrote: > We also should test FreeBSD and Cygwin. Another warning that I get on Cygwin: regex.c: In function `regerror': regex.c:8247: warning: implicit declaration of function `__mempcpy' regex.c:8247: warning: cast does not match function type I've tried to address this issue here: http://mail.gnome.org/archives/mc-devel/2003-June/msg00005.html Unfortunately noone cared to comment on this issue back then. Any thoughts ? From andrew at email.zp.ua Fri Oct 22 17:45:14 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 22 Oct 2004 20:45:14 +0300 (EEST) Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <4176BFE6.3030006@gmx.de> Message-ID: <200410221745.i9MHjEDc002713@email.zp.ua> Hello, Leonard and Roland, > We actually have (and it is important that it is) a pointer to the pathname. > > >>> q = "" <<< > q will be assigned an empty string. > > Personally, I prefer the second one, as we don't care to which empty > string q points. But this way const char * "" is passed as char *. > The function canonicalize_pathname is not suited to the problem. We This function handles ".///a" like names, and without this one tarfs says "Inconsistent tar archive" for such tar archives. > As UNC pathnames have nothing to do with Unix I wonder how the function > has found its way into util*unix*.c. This was implemented for cygwin on Pavel Tsekov request. P.S. Pavel, apply this patch, please. -- Regards, Andrew V. Samoilov. From ptsekov at gmx.net Fri Oct 22 15:56:40 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 22 Oct 2004 17:56:40 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <200410221745.i9MHjEDc002713@email.zp.ua> References: <200410221745.i9MHjEDc002713@email.zp.ua> Message-ID: Hello, On Fri, 22 Oct 2004, Andrew V. Samoilov wrote: > > As UNC pathnames have nothing to do with Unix I wonder how the function > > has found its way into util*unix*.c. > > This was implemented for cygwin on Pavel Tsekov request. Not really :) See: http://mail.gnome.org/archives/mc-devel/2004-January/msg00033.html From andrew at email.zp.ua Fri Oct 22 17:57:10 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 22 Oct 2004 20:57:10 +0300 (EEST) Subject: No question hunks from slang-1.4.6 patchset Message-ID: <200410221757.i9MHvALb003115@email.zp.ua> Hello, -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sldisply-1.4.6.c.patch URL: From ptsekov at gmx.net Fri Oct 22 16:08:36 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 22 Oct 2004 18:08:36 +0200 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> Message-ID: Hello, On Thu, 21 Oct 2004, Pavel Roskin wrote: > We also should test FreeBSD and Cygwin. This is the last warning that I see on Cygwin: ../../src/utilunix.c: In function `mc_tmpdir': ../../src/utilunix.c:404: warning: int format, uid_t arg (arg 5) `uid_t' is defined as an `unsigned long' on recent Cygwin. I see on Fedore Core 2 glib it is `unsigned int'. SUSv3 has to say the following: "nlink_t, uid_t, gid_t, and id_t shall be integer types." Based on that I guess MC code is right to assume `%d'. I don't know if and how this should be fixed. After all its not common to have uids that large. From andrew at email.zp.ua Fri Oct 22 18:06:40 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 22 Oct 2004 21:06:40 +0300 (EEST) Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: Message-ID: <200410221806.i9MI6e41003448@email.zp.ua> > Hello, > > On Fri, 22 Oct 2004, Andrew V. Samoilov wrote: > > > > As UNC pathnames have nothing to do with Unix I wonder how the function > > > has found its way into util*unix*.c. > > > > This was implemented for cygwin on Pavel Tsekov request. > > Not really :) > > See: http://mail.gnome.org/archives/mc-devel/2004-January/msg00033.html > _______________________________________________ > Mc-devel mailing list > http://mail.gnome.org/mailman/listinfo/mc-devel I am sorry... -- Regards, Andrew V. Samoilov. From andrew at email.zp.ua Fri Oct 22 18:20:54 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 22 Oct 2004 21:20:54 +0300 (EEST) Subject: Smbfs fix Message-ID: <200410221820.i9MIKsbp003886@email.zp.ua> Hi, after this patch files can be edited with external editor over smbfs. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vfs-2004-10-20.patch URL: From andrew at email.zp.ua Fri Oct 22 19:30:23 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 22 Oct 2004 22:30:23 +0300 (EEST) Subject: Patch for cmd.c Message-ID: <200410221930.i9MJUNfI006003@email.zp.ua> Hi, this patch fixes rare and almost impossible off-by-one. If user input is empty (""), these lines can do very bad thing: if (reg_exp_t [strlen(reg_exp_t) - 1] == PATH_SEP){ dirflag = 1; reg_exp_t [strlen(reg_exp_t) - 1] = 0; } It is almoust impossible to meet PATH_SEP before '\0', but sometimes it happens. -- Regards, Andrew V. Samoilov. From leonard at den.ottolander.nl Fri Oct 22 21:32:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 22 Oct 2004 23:32:27 +0200 Subject: mc-4.6.1 release? In-Reply-To: <417813A5.80202@gmx.de> References: <417813A5.80202@gmx.de> Message-ID: <1098480746.4813.5.camel@athlon.localdomain> Hi folks, Just a short note: I think the quoting issues in extfs should be fixed before the release. Please review the trpm patch I submitted earlier, and maybe we should go over the other shell scripts. Perl scripts should be fine but there might be some shell scripts that haven't been completely covered. I'll be reading the rest of your mails tomorrow and/or after the weekend. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Fri Oct 22 22:52:51 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 00:52:51 +0200 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> Message-ID: <41798F43.2040506@gmx.de> Pavel Tsekov wrote: > Hello, > > On Thu, 21 Oct 2004, Pavel Roskin wrote: > > Another warning that I get on Cygwin: > > regex.c: In function `regerror': > regex.c:8247: warning: implicit declaration of function `__mempcpy' > regex.c:8247: warning: cast does not match function type > > > I've tried to address this issue here: > > http://mail.gnome.org/archives/mc-devel/2003-June/msg00005.html I have fixed this with: - #if defined HAVE_MEMPCPY || defined _LIBC + #if 0 && (defined HAVE_MEMPCPY || defined _LIBC) I hope there won't be complaints about not discussing it in advance. Roland From roland.illig at gmx.de Fri Oct 22 22:54:47 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 00:54:47 +0200 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <200410221745.i9MHjEDc002713@email.zp.ua> References: <200410221745.i9MHjEDc002713@email.zp.ua> Message-ID: <41798FB7.4070200@gmx.de> Andrew V. Samoilov wrote: > Hello, Leonard and Roland, > > >>We actually have (and it is important that it is) a pointer to the pathname. >> >> >>> q = "" <<< >>q will be assigned an empty string. >> >>Personally, I prefer the second one, as we don't care to which empty >>string q points. > > > But this way const char * "" is passed as char *. Sorry, I didn't try to compile it so I didn't notice. Roland From roland.illig at gmx.de Sat Oct 23 06:46:20 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 08:46:20 +0200 Subject: extfs trpm In-Reply-To: <1098226050.4811.163.camel@athlon.localdomain> References: <1098225889.4811.159.camel@athlon.localdomain> <1098226050.4811.163.camel@athlon.localdomain> Message-ID: <4179FE3C.2040206@gmx.de> Leonard den Ottolander wrote: > On Wed, 2004-10-20 at 00:44, Leonard den Ottolander wrote: > >>Hi, >> >>Attached you find the proposed fixes to trpm. The SEDCMD that is used in >>rpm can not be used for the rpms file system. This should fix all the >>quoting. Increased the "file" size for UNINSTALL to 40 as the message >>"uninstalling rpm" was missing the last char. >> >>Please check for omissions and errors before committing ;) . One omission is that you did not properly quote filenames that might start with a hyphen. Imagine a weird rpm called -package-4.5.rpm. To solve this you can use mc_shellquote: mc_shellquote() { case "$1" in [A-Za-z0-9_./]*) echo "$1";; *) echo "./$1";; esac } trpm_copyout() { rpmname=`mc_shellquote "$1"` ... } Roland From roland.illig at gmx.de Sat Oct 23 06:50:36 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 08:50:36 +0200 Subject: [patch] vfs/README In-Reply-To: <1098274420.4813.34.camel@athlon.localdomain> References: <1098274420.4813.34.camel@athlon.localdomain> Message-ID: <4179FF3C.8040909@gmx.de> Leonard den Ottolander wrote: > --- README.000 1999-02-07 18:44:52.000000000 +0100 > +++ README 2004-10-20 14:11:25.000000000 +0200 > @@ -1,3 +1,8 @@ > +NOTE: Although vfs has been ment to be implemented as a separate entity > +redistributable under the LGPL in it's current implementation it uses GPLed > +code from src/ and can thus currently not be distributed under the LGPL as a > +complete package. > + I would suggest: NOTE: Although vfs has been ment to be implemented as a separate entity redistributable under the LGPL in its current implementation it uses GPLed code from src/. So there are two possibilities if you want to use vfs: 1. Distribute your copy of vfs under the GPL. Then you can freely include the GPLed functions from the rest of the mc source code. 2. Distribute your copy of vfs under the LGPL. Then you cannot include the functions outside the vfs subdirectory. You must then either rewrite them or work around them in other ways. Roland From roland.illig at gmx.de Sat Oct 23 07:03:19 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 09:03:19 +0200 Subject: mc-4.6.1 release? In-Reply-To: <20041022021242.GA6713@hindus.hstl5.put.poznan.pl> References: <417813A5.80202@gmx.de> <41784186.8040703@gmx.de> <20041022021242.GA6713@hindus.hstl5.put.poznan.pl> Message-ID: <417A0237.8010805@gmx.de> q# wrote: > [1] http://kubek.eu.org/~hns/pub/mc/build-log/ Looks great. I have written another test suite for mc which separates the log files into {configure,make_all,make_check,make_install}.{out,err}. That way I can see the warnings better. You can call the testsuite with: $ mc-tests.sh -cvs-repository ":ext:anoncvs at cvs.gnu.org:/cvsroot/mc" It will take about an hour to complete. Then you find lots of log files in ${TMPDIR-"/tmp"}/mc/logs. Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-tests.sh Type: application/x-sh Size: 14178 bytes Desc: not available URL: From roland.illig at gmx.de Sat Oct 23 07:10:06 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 09:10:06 +0200 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> Message-ID: <417A03CE.7040806@gmx.de> Pavel Tsekov wrote: > -#if (!(defined(__linux__) && defined (__USE_GNU))) > +#if (!(defined(__linux__) && defined (__USE_GNU)) && !defined(__CYGWIN__)) Committed. Thanks. Roland From eth0 at o2.pl Sat Oct 23 07:16:59 2004 From: eth0 at o2.pl (q#) Date: Sat, 23 Oct 2004 09:16:59 +0200 Subject: mc-4.6.1 release? In-Reply-To: <417A0237.8010805@gmx.de> References: <417813A5.80202@gmx.de> <41784186.8040703@gmx.de> <20041022021242.GA6713@hindus.hstl5.put.poznan.pl> <417A0237.8010805@gmx.de> Message-ID: <20041023071659.GB1818@hindus.hstl5.put.poznan.pl> On Sat, Oct 23, 2004 at 09:03:19AM +0200, Roland Illig wrote: > q# wrote: > >[1] http://kubek.eu.org/~hns/pub/mc/build-log/ > > Looks great. > > I have written another test suite for mc which separates the log files > into {configure,make_all,make_check,make_install}.{out,err}. That way I > can see the warnings better. > > You can call the testsuite with: > > $ mc-tests.sh -cvs-repository ":ext:anoncvs at cvs.gnu.org:/cvsroot/mc" > > It will take about an hour to complete. Then you find lots of log files > in ${TMPDIR-"/tmp"}/mc/logs. > > Roland On OpenBSD-current gettext is 0.10.40 and automake in 1.4 version, so that's why I've build from snapshot. I'am working on gettext now to update it to required minimum 0.11.5. It may take some time, as I'm newbie in *bsd world. -- best regards q# From roland.illig at gmx.de Sat Oct 23 07:25:14 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 09:25:14 +0200 Subject: mc-4.6.1 release? In-Reply-To: <1098480746.4813.5.camel@athlon.localdomain> References: <417813A5.80202@gmx.de> <1098480746.4813.5.camel@athlon.localdomain> Message-ID: <417A075A.3040501@gmx.de> Leonard den Ottolander wrote: > Hi folks, > > Just a short note: I think the quoting issues in extfs should be fixed > before the release. I have added the list of all files in vfs/extfs to the /TODO list. We should make "final" patches (one per file) that fix all the issues we know of. When committing such a final patch, please don't forget to delete the appropriate line from /TODO. Roland From roland.illig at gmx.de Sat Oct 23 08:37:04 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 10:37:04 +0200 Subject: extfs Message-ID: <417A1830.1050808@gmx.de> Hi, I have written two new files to make writing secure, robust extfs shell scripts easier. I have not yet tested them. Thoughts? Roland -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: template.sh.in URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: extfs.subr.sh.in URL: From leonard at den.ottolander.nl Sat Oct 23 11:29:01 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 13:29:01 +0200 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> Message-ID: <1098530941.4813.1.camel@athlon.localdomain> Hello Pavel, On Fri, 2004-10-22 at 18:08, Pavel Tsekov wrote: > `uid_t' is defined as an `unsigned long' on recent Cygwin. I see on > Fedore Core 2 glib it is `unsigned int'. SUSv3 has to say the > following: > > "nlink_t, uid_t, gid_t, and id_t shall be integer types." Seems like you should take up the issue with the Cygwin developers then. I don't know how authoritative the above statement is, but the easiest way to find out is probably to put it to the Cygwin developers to comment on. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 11:34:34 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 13:34:34 +0200 Subject: mc-4.6.1 release? In-Reply-To: <41798F43.2040506@gmx.de> References: <417813A5.80202@gmx.de> <41798F43.2040506@gmx.de> Message-ID: <1098531273.4813.4.camel@athlon.localdomain> Hello Roland, On Sat, 2004-10-23 at 00:52, Roland Illig wrote: > > http://mail.gnome.org/archives/mc-devel/2003-June/msg00005.html > > I have fixed this with: > - #if defined HAVE_MEMPCPY || defined _LIBC > + #if 0 && (defined HAVE_MEMPCPY || defined _LIBC) Where exactly did you apply this and does it affect other platforms than Cygwin? Seems like a rather crude hack to me. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 11:38:46 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 13:38:46 +0200 Subject: extfs trpm In-Reply-To: <4179FE3C.2040206@gmx.de> References: <1098225889.4811.159.camel@athlon.localdomain> <1098226050.4811.163.camel@athlon.localdomain> <4179FE3C.2040206@gmx.de> Message-ID: <1098531525.4813.6.camel@athlon.localdomain> Hello Roland, On Sat, 2004-10-23 at 08:46, Roland Illig wrote: > mc_shellquote() { > case "$1" in [A-Za-z0-9_./]*) echo "$1";; *) echo "./$1";; esac > } > > trpm_copyout() { > rpmname=`mc_shellquote "$1"` > ... > } Right. Could you merge this fix with the existing patch and resubmit the fixed patch for review to the list? TIA. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 11:42:55 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 13:42:55 +0200 Subject: [patch] vfs/README In-Reply-To: <4179FF3C.8040909@gmx.de> References: <1098274420.4813.34.camel@athlon.localdomain> <4179FF3C.8040909@gmx.de> Message-ID: <1098531775.4813.11.camel@athlon.localdomain> Hello Roland, On Sat, 2004-10-23 at 08:50, Roland Illig wrote: > NOTE: Although vfs has been ment to be implemented as a separate entity "Ment" should have been "meant". Please correct. > redistributable under the LGPL in its current implementation it uses > GPLed code from src/. So there are two possibilities if you want to use vfs: > > 1. Distribute your copy of vfs under the GPL. Then you can freely > include the GPLed functions from the rest of the mc source code. > > 2. Distribute your copy of vfs under the LGPL. Then you cannot include > the functions outside the vfs subdirectory. You must then either rewrite > them or work around them in other ways. I have no objections against this change. Please commit so people can read it while we work on solving this issue. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 11:52:00 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 13:52:00 +0200 Subject: mc-4.6.1 release? In-Reply-To: <417A075A.3040501@gmx.de> References: <417813A5.80202@gmx.de> <1098480746.4813.5.camel@athlon.localdomain> <417A075A.3040501@gmx.de> Message-ID: <1098532320.4813.21.camel@athlon.localdomain> On Sat, 2004-10-23 at 09:25, Roland Illig wrote: > I have added the list of all files in vfs/extfs to the /TODO list. All the perl scripts have been audited before and can be deleted from the TODO. Please remove a.in, apt.in, deb.in, deba.in, debd.in and dpkg.in as all quoting issues are fixed in these scripts. Other perl scripts for which I didn't find quoting vulnerabilities: mailfs.in, patchfs.in, rpms.in and uzip.in. Also fixed and committed are audio.in and hp48.in although these and the previous (not the first 6) perl scripts might be double checked for things like the "dash issue". Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 12:22:31 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 14:22:31 +0200 Subject: LGPL code using GPL code In-Reply-To: <1098300428.7484.262.camel@linux.site> References: <1098205084.4811.129.camel@athlon.localdomain> <417592E3.7050407@gmx.de> <1098299778.4901.92.camel@athlon.localdomain> <1098300428.7484.262.camel@linux.site> Message-ID: <1098534146.4813.53.camel@athlon.localdomain> Hello Miguel, On Wed, 2004-10-20 at 21:27, Miguel de Icaza wrote: > For any code that I wrote (you might check the CVS logs) I can grant > relicensing rights to the code under the LGPL. Well, that's a great start (assuming there is need to distribute vfs under the LGPL separately ;) ). Is this grant for the whole files or just the affected functions? I.e. do we need to separate the affected functions out? And of course there is the issue of other people touching those files/functions. I believe everybody touching those files should grant such relicensing rights. Not sure how we should handle cases where the original author of patches is not named in the change logs. > > src/execute.c: > > shell_execute > > I dont remember that one. Created by Pavel Roskin, 2003-06-22. Only touched by Pavel Shirshov and Roland afaict. > > src/slint.c: > > disable_interrupt_key > > enable_interrupt_key > > got_interrupt > > I believe I implemented those. Touched by quite a few others as well. > > decompress_extension > > Jakub most likely did this and a few others. Jakub, do you have any objections against relicensing the parts necessary for vfs to LGPL? > For the record, I dont object to move any of my contributions from GPL > to LGPL if it serves the team's effort. That is good to know. Thanks. Any idea about the opinion on this matter of the others you mention? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 12:27:21 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 14:27:21 +0200 Subject: mc on SunOS In-Reply-To: <41784326.5090500@gmx.de> References: <41784326.5090500@gmx.de> Message-ID: <1098534441.4813.56.camel@athlon.localdomain> Hello Roland, On Fri, 2004-10-22 at 01:15, Roland Illig wrote: > @@ -326,7 +335,7 @@ mc_tmpdir (void) > pwd->pw_name); > else > g_snprintf (buffer, sizeof (buffer), "%s/mc-%d", sys_tmp, > - getuid ()); > + (int) getuid ()); > > canonicalize_pathname (buffer); This seems correct, but is it in any way related to mc on SunOS? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Sat Oct 23 12:29:47 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 14:29:47 +0200 Subject: [patch] vfs/README In-Reply-To: <1098531775.4813.11.camel@athlon.localdomain> References: <1098274420.4813.34.camel@athlon.localdomain> <4179FF3C.8040909@gmx.de> <1098531775.4813.11.camel@athlon.localdomain> Message-ID: <417A4EBB.3070604@gmx.de> Leonard den Ottolander wrote: > I have no objections against this change. Please commit so people can > read it while we work on solving this issue. done. Roland From juancri at juancri.com Fri Oct 22 19:54:16 2004 From: juancri at juancri.com (Juan C. Olivares) Date: Fri, 22 Oct 2004 16:54:16 -0300 (CLST) Subject: aspx syntax file Message-ID: Hi: This is a new Syntax file for ASP.NET. This includes: .aspx Web Forms .ashx Web Handlers .asmx Web Services .ascx Web User Control .asax Web Application Global Class I think it's complete. It does not highlight C#/VB.NET code within a page... as HTML does not highlight PHP code on Web pages :) I added these two lines to my Syntax file: file ..\*\\.(asax|aspx|ascx|asmx|ashx)$ ASPX\sFile include aspx.syntax Juan C. Olivares www.juancri.com -------------- next part -------------- # ASP.NET syntax highlighting # # Author: Juan C. Olivares # http://www.juancri.com context default keyword "*" lightgray keyword '*' lightgray spellcheck context brightgreen spellcheck context yellow keyword '+' brightcyan keyword "+" brightcyan keyword \( lightgray keyword \) lightgray keyword \* lightgray keyword \? lightgray keyword \+ lightgray keyword \| lightgray keyword \, lightgray spellcheck context <% %> brightgreen keyword Application white keyword Assembly white keyword Control white keyword Implements white keyword Import white keyword Inherits white keyword OutputCache white keyword Page white keyword Reference white keyword Register white keyword WebService white keyword \s+\= yellow keyword '*' brightcyan keyword "*" brightcyan spellcheck context < > white keyword \s+\= yellow keyword "server" brightgreen keyword '*' brightcyan keyword "*" brightcyan spellcheck From roland.illig at gmx.de Sat Oct 23 12:39:17 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 14:39:17 +0200 Subject: mc-4.6.1 release? In-Reply-To: <1098531273.4813.4.camel@athlon.localdomain> References: <417813A5.80202@gmx.de> <41798F43.2040506@gmx.de> <1098531273.4813.4.camel@athlon.localdomain> Message-ID: <417A50F5.3070401@gmx.de> Leonard den Ottolander wrote: > Hello Roland, > > On Sat, 2004-10-23 at 00:52, Roland Illig wrote: > >>>http://mail.gnome.org/archives/mc-devel/2003-June/msg00005.html >> >>I have fixed this with: >>- #if defined HAVE_MEMPCPY || defined _LIBC >>+ #if 0 && (defined HAVE_MEMPCPY || defined _LIBC) > > > Where exactly did you apply this and does it affect other platforms than > Cygwin? Seems like a rather crude hack to me. line 8246 I would rather consider it a bugfix around a crude hack. After querying HAVE_MEMPCPY you have no guarantee that you have the function __mempcpy, and in portable programs you should not try to call it then. And even then, the __mempcpy version saves only one or two assembler instructions compared to the non-__mempcpy version. The semantics are the same in both branches. Roland From leonard at den.ottolander.nl Sat Oct 23 12:44:34 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 14:44:34 +0200 Subject: patchfs: Fixed leading ./ bug In-Reply-To: <417903E1.1010208@gmx.de> References: <417903E1.1010208@gmx.de> Message-ID: <1098535473.4813.72.camel@athlon.localdomain> Hello Roland, On Fri, 2004-10-22 at 14:58, Roland Illig wrote: > [ ] needs review x > + $fname =~ s,/+,/,g; ? Can you just remove the plus sign? > + $fname =~ s,/\.$,,; Why is this needed? > $file=~s/^(PATCH-(CREATE|REMOVE)\/)?(.*)\.diff$/$3/; > + $file = mc_canonicalize_path ($file); What happened to the ".diff$" part? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 12:54:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 14:54:43 +0200 Subject: No question hunks from slang-1.4.6 patchset In-Reply-To: <200410221757.i9MHvALb003115@email.zp.ua> References: <200410221757.i9MHvALb003115@email.zp.ua> Message-ID: <1098536083.4813.77.camel@athlon.localdomain> On Fri, 2004-10-22 at 19:57, Andrew V. Samoilov wrote: > Hello, > - I very much object to this part of the patch ;-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Sat Oct 23 12:55:17 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 14:55:17 +0200 Subject: mc-4.6.1 release? In-Reply-To: <1098530941.4813.1.camel@athlon.localdomain> References: <417813A5.80202@gmx.de> <1098530941.4813.1.camel@athlon.localdomain> Message-ID: <417A54B5.1040907@gmx.de> Leonard den Ottolander wrote: > Hello Pavel, > > On Fri, 2004-10-22 at 18:08, Pavel Tsekov wrote: > >>`uid_t' is defined as an `unsigned long' on recent Cygwin. I see on >>Fedore Core 2 glib it is `unsigned int'. SUSv3 has to say the >>following: >> >> "nlink_t, uid_t, gid_t, and id_t shall be integer types." > > > Seems like you should take up the issue with the Cygwin developers then. > I don't know how authoritative the above statement is, but the easiest > way to find out is probably to put it to the Cygwin developers to > comment on. I don't think the issue is that important in this case. A conversion to an unsigned long should be enough in all practical cases. An unsigned long has at least 32 bits, so the only case in which there could be name clashes are when two distinct users on a system dont have a username and when their (uid & 0xffffffff) are the same. Roland From roland.illig at gmx.de Sat Oct 23 12:56:39 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 14:56:39 +0200 Subject: mc on SunOS In-Reply-To: <1098534441.4813.56.camel@athlon.localdomain> References: <41784326.5090500@gmx.de> <1098534441.4813.56.camel@athlon.localdomain> Message-ID: <417A5507.6090109@gmx.de> Leonard den Ottolander wrote: > Hello Roland, > > On Fri, 2004-10-22 at 01:15, Roland Illig wrote: > >>@@ -326,7 +335,7 @@ mc_tmpdir (void) >> pwd->pw_name); >> else >> g_snprintf (buffer, sizeof (buffer), "%s/mc-%d", sys_tmp, >>- getuid ()); >>+ (int) getuid ()); >> >> canonicalize_pathname (buffer); > > > This seems correct, but is it in any way related to mc on SunOS? gcc emitted a warning on SunOS, but not on Linux. ;) Roland From roland.illig at gmx.de Sat Oct 23 13:01:37 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 15:01:37 +0200 Subject: patchfs: Fixed leading ./ bug In-Reply-To: <1098535473.4813.72.camel@athlon.localdomain> References: <417903E1.1010208@gmx.de> <1098535473.4813.72.camel@athlon.localdomain> Message-ID: <417A5631.3090303@gmx.de> Leonard den Ottolander wrote: > Hello Roland, > On Fri, 2004-10-22 at 14:58, Roland Illig wrote: > >>+ $fname =~ s,/+,/,g; > ? Can you just remove the plus sign? Why do you want to replace every "/" with "/"? >>+ $fname =~ s,/\.$,,; > Why is this needed? Because "dir/subdir/." and "dir/subdir" are handled the same in the rest of mc. >> $file=~s/^(PATCH-(CREATE|REMOVE)\/)?(.*)\.diff$/$3/; >>+ $file = mc_canonicalize_path ($file); > > What happened to the ".diff$" part? I don't know. That has not been me. Roland From leonard at den.ottolander.nl Sat Oct 23 13:24:59 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 15:24:59 +0200 Subject: mc-4.6.1 release? In-Reply-To: <417A54B5.1040907@gmx.de> References: <417813A5.80202@gmx.de> <1098530941.4813.1.camel@athlon.localdomain> <417A54B5.1040907@gmx.de> Message-ID: <1098537899.4813.82.camel@athlon.localdomain> Hi Roland, On Sat, 2004-10-23 at 14:55, Roland Illig wrote: > I don't think the issue is that important in this case. A conversion to > an unsigned long should be enough in all practical cases. An unsigned > long has at least 32 bits, so the only case in which there could be name > clashes are when two distinct users on a system dont have a username and > when their (uid & 0xffffffff) are the same. Do I understand correctly that you want to introduce a cast because there's a bug in Cygwin? If so, I don't think that is a correct approach. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 13:33:11 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 15:33:11 +0200 Subject: patchfs: Fixed leading ./ bug In-Reply-To: <417A5631.3090303@gmx.de> References: <417903E1.1010208@gmx.de> <1098535473.4813.72.camel@athlon.localdomain> <417A5631.3090303@gmx.de> Message-ID: <1098538391.4813.91.camel@athlon.localdomain> Hello Roland, On Sat, 2004-10-23 at 15:01, Roland Illig wrote: > >>+ $fname =~ s,/+,/,g; > > ? Can you just remove the plus sign? > > Why do you want to replace every "/" with "/"? That obviously is *not* what I am asking. My question is whether it is safe to remove all plus signs from $fname (no not *all*, but all that are preceded by a slash), not from the above expression. > >>+ $fname =~ s,/\.$,,; > > Why is this needed? > > Because "dir/subdir/." and "dir/subdir" are handled the same in the rest > of mc. Yes, but this is about patchfs, right? The content of a diff is about files, not directories, so this catch seems redundant. If you want this to be a more general function for use in other shell scripts it's rather incomplete. > >> $file=~s/^(PATCH-(CREATE|REMOVE)\/)?(.*)\.diff$/$3/; > >>+ $file = mc_canonicalize_path ($file); > > > > What happened to the ".diff$" part? > > I don't know. That has not been me. Another misunderstanding. This is your patch right? Why don't you catch the .diff$ part? The first expression seems to strip it from the resulting $file, but I think you don't do that with your expression. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Oct 23 13:39:03 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 15:39:03 +0200 Subject: patchfs: Fixed leading ./ bug In-Reply-To: <1098538391.4813.91.camel@athlon.localdomain> References: <417903E1.1010208@gmx.de> <1098535473.4813.72.camel@athlon.localdomain> <417A5631.3090303@gmx.de> <1098538391.4813.91.camel@athlon.localdomain> Message-ID: <1098538743.4813.96.camel@athlon.localdomain> Hi, I wrote: > > >> $file=~s/^(PATCH-(CREATE|REMOVE)\/)?(.*)\.diff$/$3/; > > >>+ $file = mc_canonicalize_path ($file); > > > > > > What happened to the ".diff$" part? > > > > I don't know. That has not been me. > > Another misunderstanding. This is your patch right? Why don't you catch > the .diff$ part? The first expression seems to strip it from the > resulting $file, but I think you don't do that with your expression. Duh. I read a - where there was none. Please disregard these remarks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Sat Oct 23 13:41:08 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 15:41:08 +0200 Subject: patchfs: Fixed leading ./ bug In-Reply-To: <1098538391.4813.91.camel@athlon.localdomain> References: <417903E1.1010208@gmx.de> <1098535473.4813.72.camel@athlon.localdomain> <417A5631.3090303@gmx.de> <1098538391.4813.91.camel@athlon.localdomain> Message-ID: <417A5F74.8020402@gmx.de> Leonard den Ottolander wrote: > Hello Roland, > > On Sat, 2004-10-23 at 15:01, Roland Illig wrote: > >>>>+ $fname =~ s,/+,/,g; >>> >>>? Can you just remove the plus sign? >> >>Why do you want to replace every "/" with "/"? > > > That obviously is *not* what I am asking. My question is whether it is > safe to remove all plus signs from $fname (no not *all*, but all that > are preceded by a slash), not from the above expression. The + sign matches 1 or more slashes. A literal + would have been \+. > Yes, but this is about patchfs, right? The content of a diff is about > files, not directories, so this catch seems redundant. If you want this > to be a more general function for use in other shell scripts it's rather > incomplete. accepted. >>>> $file=~s/^(PATCH-(CREATE|REMOVE)\/)?(.*)\.diff$/$3/; >>>>+ $file = mc_canonicalize_path ($file); >>> >>>What happened to the ".diff$" part? >> >>I don't know. That has not been me. > > Another misunderstanding. This is your patch right? Why don't you catch > the .diff$ part? The first expression seems to strip it from the > resulting $file, but I think you don't do that with your expression. I just added the mc_canonicalize_path line. The first line is still active after the patch. Roland From leonard at den.ottolander.nl Sat Oct 23 13:59:14 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 23 Oct 2004 15:59:14 +0200 Subject: patchfs: Fixed leading ./ bug In-Reply-To: <417A5F74.8020402@gmx.de> References: <417903E1.1010208@gmx.de> <1098535473.4813.72.camel@athlon.localdomain> <417A5631.3090303@gmx.de> <1098538391.4813.91.camel@athlon.localdomain> <417A5F74.8020402@gmx.de> Message-ID: <1098539954.4813.97.camel@athlon.localdomain> On Sat, 2004-10-23 at 15:41, Roland Illig wrote: > The + sign matches 1 or more slashes. A literal + would have been \+. Yes. I got that now. Man I feel silly ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nerijus at users.sourceforge.net Sat Oct 23 14:33:22 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Sat, 23 Oct 2004 17:33:22 +0300 (EEST) Subject: building on AIX Message-ID: <20041023143255.0CD41508412@mx.ktv.lt> Hello, I try to build latest mc snapshot on AIX 5.1. By just running configure I get: checking for SLsmg_write_nwchars in -lslang... no checking for SLang_init_tty in -lslang... yes checking slang.h usability... no checking slang.h presence... no checking for slang.h... no checking slang/slang.h usability... yes checking slang/slang.h presence... yes checking for slang/slang.h... yes Screen library: S-Lang library (installed on the system) But compiling fails: key.c: In function `init_key_input_fd': key.c:514: `SLang_TT_Read_FD' undeclared (first use in this function) key.c:514: (Each undeclared identifier is reported only once key.c:514: for each function it appears in.) make: 1254-004 The error code from the last command is 1. Shouldn't configure check for SLang_TT_Read_FD in system slang? Then I looked in mc.spec and configured according to it --with-screen=ncurses --with-screen=mcslang --enable-charset (btw, why mc.spec uses both ncurses and mcslang? IMHO only one should be defined). Screen library: Included S-Lang library (mcslang) Compiling still fails: Making all in slang ... slsmg.c:82: `SLtt_Has_Alt_Charset' undeclared here (not in a function) slsmg.c:84: `SLtt_Use_Blink_For_ACS' undeclared here (not in a function) make: 1254-004 The error code from the last command is 1. BTW, there is one warning in ftpfs.c: ftpfs.c: In function `ftpfs_initconn': ftpfs.c:889: warning: passing arg 3 of `ngetsockname' from incompatible pointer type ftpfs.c:912: warning: passing arg 3 of `ngetsockname' from incompatible pointer type ftpfs.c: In function `ftpfs_open_data_connection': ftpfs.c:957: warning: passing arg 3 of `naccept' from incompatible pointer type Regards, Nerijus From roland.illig at gmx.de Sat Oct 23 18:51:05 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 20:51:05 +0200 Subject: building on AIX In-Reply-To: <20041023143255.0CD41508412@mx.ktv.lt> References: <20041023143255.0CD41508412@mx.ktv.lt> Message-ID: <417AA819.8070302@gmx.de> Nerijus Baliunas wrote: > ftpfs.c: In function `ftpfs_initconn': > ftpfs.c:889: warning: passing arg 3 of `ngetsockname' from incompatible pointer type > ftpfs.c:912: warning: passing arg 3 of `ngetsockname' from incompatible pointer type > ftpfs.c: In function `ftpfs_open_data_connection': > ftpfs.c:957: warning: passing arg 3 of `naccept' from incompatible pointer type Thanks for reporting these. The patch is to add an AC_CHECK_TYPE(socklen_t, size_t) to configure.ac and then replace the types in all the wrong declarations with socklen_t. Concerning socklen_t.patch: [ ] ok to commit [ ] needs review [ ] rejected Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: socklen_t.patch Type: text/x-patch Size: 1325 bytes Desc: not available URL: From ptsekov at gmx.net Sat Oct 23 17:01:42 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Sat, 23 Oct 2004 19:01:42 +0200 Subject: mc-4.6.1 release? In-Reply-To: <1098537899.4813.82.camel@athlon.localdomain> References: <417813A5.80202@gmx.de> <1098530941.4813.1.camel@athlon.localdomain> <417A54B5.1040907@gmx.de> <1098537899.4813.82.camel@athlon.localdomain> Message-ID: On Sat, 23 Oct 2004, Leonard den Ottolander wrote: > Hi Roland, > > On Sat, 2004-10-23 at 14:55, Roland Illig wrote: > > I don't think the issue is that important in this case. A conversion to > > an unsigned long should be enough in all practical cases. An unsigned > > long has at least 32 bits, so the only case in which there could be name > > clashes are when two distinct users on a system dont have a username and > > when their (uid & 0xffffffff) are the same. > > Do I understand correctly that you want to introduce a cast because > there's a bug in Cygwin? If so, I don't think that is a correct > approach. There is no bug on Cygwin as there is no bug on Linux. As you can easily see for yourself both define uid_t as `unsigned' type. With extremely large values greater that INT_MAX you will get wrong result with the format type specifier %d. I quoted SUSv3 as a reference - from the text it is clear that it is up to the vendor whether uid_t is signed or not since it is not explicitly specified. From ptsekov at gmx.net Sat Oct 23 17:02:10 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Sat, 23 Oct 2004 19:02:10 +0200 Subject: mc-4.6.1 release? In-Reply-To: <1098531273.4813.4.camel@athlon.localdomain> References: <417813A5.80202@gmx.de> <41798F43.2040506@gmx.de> <1098531273.4813.4.camel@athlon.localdomain> Message-ID: Hello, On Sat, 23 Oct 2004, Leonard den Ottolander wrote: > Hello Roland, > > On Sat, 2004-10-23 at 00:52, Roland Illig wrote: > > > http://mail.gnome.org/archives/mc-devel/2003-June/msg00005.html > > > > I have fixed this with: > > - #if defined HAVE_MEMPCPY || defined _LIBC > > + #if 0 && (defined HAVE_MEMPCPY || defined _LIBC) > > Where exactly did you apply this and does it affect other platforms than > Cygwin? Seems like a rather crude hack to me. Have you read the link that I posted ? It is clear that __mempcpy is too glibc specific. And even worse - the configure test doesn't test for __mempcpy, but mempcpy. This is clearly wrong. From miguel at ximian.com Sat Oct 23 17:35:40 2004 From: miguel at ximian.com (Miguel de Icaza) Date: Sat, 23 Oct 2004 13:35:40 -0400 Subject: LGPL code using GPL code In-Reply-To: <1098534146.4813.53.camel@athlon.localdomain> References: <1098205084.4811.129.camel@athlon.localdomain> <417592E3.7050407@gmx.de> <1098299778.4901.92.camel@athlon.localdomain> <1098300428.7484.262.camel@linux.site> <1098534146.4813.53.camel@athlon.localdomain> Message-ID: <1098552940.7484.492.camel@linux.site> Hello, > > For any code that I wrote (you might check the CVS logs) I can grant > > relicensing rights to the code under the LGPL. > > Well, that's a great start (assuming there is need to distribute vfs > under the LGPL separately ;) ). Is this grant for the whole files or > just the affected functions? I.e. do we need to separate the affected > functions out? For anything that you might need to split the VFS out. Am personally not sure if the VFS on its own is very useful as today there are a few other approaches that seem to have worked fairly well (the podfuks of the world), but I figured at least I did not get in your way of trying. > And of course there is the issue of other people touching those > files/functions. I believe everybody touching those files should grant > such relicensing rights. Not sure how we should handle cases where the > original author of patches is not named in the change logs. Exactly. You might be able to get this information from the ChangeLog and from CVS. It might be hard work though. Miguel From roland.illig at gmx.de Sat Oct 23 20:16:43 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 23 Oct 2004 22:16:43 +0200 Subject: building on AIX In-Reply-To: <417AA819.8070302@gmx.de> References: <20041023143255.0CD41508412@mx.ktv.lt> <417AA819.8070302@gmx.de> Message-ID: <417ABC2B.8020400@gmx.de> Roland Illig wrote: > +AC_CHECK_TYPE(socklen_t, size_t) Perhaps it might be better to fall back to int, as the code currently uses ints. Roland From leonard at den.ottolander.nl Sat Oct 23 23:08:29 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 24 Oct 2004 01:08:29 +0200 Subject: mc-4.6.1 release? In-Reply-To: References: <417813A5.80202@gmx.de> <1098530941.4813.1.camel@athlon.localdomain> <417A54B5.1040907@gmx.de> <1098537899.4813.82.camel@athlon.localdomain> Message-ID: <1098572909.4782.3.camel@athlon.localdomain> Hi Pavel, On Sat, 2004-10-23 at 19:01, Pavel Tsekov wrote: > There is no bug on Cygwin as there is no bug on Linux. It seems I was a bit dense today. I interpreted "needs to be an integer type" as being "needs to be a 32 bit integer". Sorry for the mix up. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From pavelsh at mail.ru Sat Oct 23 22:22:53 2004 From: pavelsh at mail.ru (pavelsh) Date: Sun, 24 Oct 2004 04:22:53 +0600 Subject: Import slang-1.4.9 patch Message-ID: <166565075.20041024042253@mail.ru> Hello mc-devel, Please, check my patch (import libslang-1.4.9 into mcslang). It's working fine for me. P.S.:FreeBSD-5.2.1 -- Best regards, pavelsh mailto:pavelsh at mail.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: slang.patch Type: application/octet-stream Size: 39865 bytes Desc: not available URL: From me at pavelsh.pp.ru Mon Oct 25 08:12:40 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Mon, 25 Oct 2004 14:12:40 +0600 Subject: Smbfs fix In-Reply-To: <200410221820.i9MIKsbp003886@email.zp.ua> References: <200410221820.i9MIKsbp003886@email.zp.ua> Message-ID: <1072052089.20041025141240@pavelsh.pp.ru> Hello Andrew, Saturday, October 23, 2004, 12:20:54 AM, you wrote: AVS> Hi, AVS> after this patch files can be edited with external editor over smbfs. Committed. Thx -- Best regards, Pavel mailto:me at pavelsh.pp.ru From andrew at email.zp.ua Mon Oct 25 09:25:24 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 25 Oct 2004 12:25:24 +0300 (EEST) Subject: Patch for cmd.c In-Reply-To: <200410221930.i9MJUNfI006003@email.zp.ua> Message-ID: <200410250925.i9P9POPi001792@email.zp.ua> Hi, > > this patch fixes rare and almost impossible off-by-one. > If user input is empty (""), these lines can do very bad thing: > > if (reg_exp_t [strlen(reg_exp_t) - 1] == PATH_SEP){ > dirflag = 1; > reg_exp_t [strlen(reg_exp_t) - 1] = 0; > } > > It is almoust impossible to meet PATH_SEP before '\0', but sometimes it happens. Patch attached, sorry for inconvenience. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmd.c.patch URL: From me at pavelsh.pp.ru Mon Oct 25 09:36:18 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Mon, 25 Oct 2004 15:36:18 +0600 Subject: Patch for cmd.c In-Reply-To: <200410250925.i9P9POPi001792@email.zp.ua> References: <200410221930.i9MJUNfI006003@email.zp.ua> <200410250925.i9P9POPi001792@email.zp.ua> Message-ID: <836172841.20041025153618@pavelsh.pp.ru> Hello Andrew, Monday, October 25, 2004, 3:25:24 PM, you wrote: AVS> Hi, >> >> this patch fixes rare and almost impossible off-by-one. >> If user input is empty (""), these lines can do very bad thing: >> >> if (reg_exp_t [strlen(reg_exp_t) - 1] == PATH_SEP){ >> dirflag = 1; >> reg_exp_t [strlen(reg_exp_t) - 1] = 0; >> } >> >> It is almoust impossible to meet PATH_SEP before '\0', but sometimes it happens. AVS> Patch attached, sorry for inconvenience. Committed. Thx -- Best regards, Pavel mailto:me at pavelsh.pp.ru From andrew at email.zp.ua Mon Oct 25 10:12:50 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 25 Oct 2004 13:12:50 +0300 (EEST) Subject: No question hunks from slang-1.4.6 patchset In-Reply-To: <1098536083.4813.77.camel@athlon.localdomain> Message-ID: <200410251012.i9PACo31003385@email.zp.ua> Hello, > > - > > I very much object to this part of the patch ;-) . What kind of part? -- Regards, Andrew V. Samoilov. From nerijus at users.sourceforge.net Mon Oct 25 11:38:42 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 25 Oct 2004 14:38:42 +0300 (EEST) Subject: Import slang-1.4.9 patch In-Reply-To: <166565075.20041024042253@mail.ru> References: <166565075.20041024042253@mail.ru> Message-ID: <20041025113856.D65B75080B1@mx.ktv.lt> On Sun, 24 Oct 2004 04:22:53 +0600 pavelsh wrote: > Please, check my patch (import libslang-1.4.9 into mcslang). With this patch make still fails with the same error on AIX: slsmg.c:76: `SLtt_Has_Alt_Charset' undeclared here (not in a function) slsmg.c:78: `SLtt_Use_Blink_For_ACS' undeclared here (not in a function) make: 1254-004 The error code from the last command is 1. Regards, Nerijus From andrew at email.zp.ua Mon Oct 25 11:50:24 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 25 Oct 2004 14:50:24 +0300 (EEST) Subject: mc on SunOS In-Reply-To: <41784326.5090500@gmx.de> Message-ID: <200410251150.i9PBoOeY006415@email.zp.ua> Hi, Roland > any complaints about this patch? IMHO it's better to rewrite mc_tempdir() with putenv(). -- Regards, Andrew V. Samoilov. From andrew at email.zp.ua Mon Oct 25 12:12:28 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 25 Oct 2004 15:12:28 +0300 (EEST) Subject: Some VFS issues Message-ID: <200410251212.i9PCCSHe007094@email.zp.ua> Hello, I think vfs/ChangeLog part is quit enough ;-) -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vfs.c.patch URL: From leonard at den.ottolander.nl Mon Oct 25 12:13:51 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 25 Oct 2004 14:13:51 +0200 Subject: No question hunks from slang-1.4.6 patchset In-Reply-To: <200410251012.i9PACo31003385@email.zp.ua> References: <200410251012.i9PACo31003385@email.zp.ua> Message-ID: <1098706431.4809.0.camel@athlon.localdomain> Hi Andrew, On Mon, 2004-10-25 at 12:12, Andrew V. Samoilov wrote: > Hello, > > > - > > > > I very much object to this part of the patch ;-) . > > What kind of part? The quoted part. The empty line you remove. This was supposed to be a joke. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Mon Oct 25 12:20:28 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Mon, 25 Oct 2004 18:20:28 +0600 Subject: Some VFS issues In-Reply-To: <200410251212.i9PCCSHe007094@email.zp.ua> References: <200410251212.i9PCCSHe007094@email.zp.ua> Message-ID: <19410265226.20041025182028@pavelsh.pp.ru> Hello Andrew, Monday, October 25, 2004, 6:12:28 PM, you wrote: AVS> Hello, AVS> I think vfs/ChangeLog part is quit enough ;-) Committed. Thx -- Best regards, Pavel mailto:me at pavelsh.pp.ru From andrew at email.zp.ua Mon Oct 25 12:23:42 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 25 Oct 2004 15:23:42 +0300 (EEST) Subject: Import slang-1.4.9 patch In-Reply-To: <20041025113856.D65B75080B1@mx.ktv.lt> Message-ID: <200410251223.i9PCNg0X007452@email.zp.ua> Hello, Nerijus > On Sun, 24 Oct 2004 04:22:53 +0600 pavelsh wrote: > > > Please, check my patch (import libslang-1.4.9 into mcslang). > > With this patch make still fails with the same error on AIX: > > slsmg.c:76: `SLtt_Has_Alt_Charset' undeclared here (not in a function) > slsmg.c:78: `SLtt_Use_Blink_For_ACS' undeclared here (not in a function) > make: 1254-004 The error code from the last command is 1. Does AIX really not define unix, __unix or __unix__? Does it define __GO32__ ? Well, if your first answer is Yes and second is NO, patch below can help you. Test it, please. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: slang.h.AIX.patch URL: From nerijus at users.sourceforge.net Mon Oct 25 12:41:35 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 25 Oct 2004 15:41:35 +0300 (EEST) Subject: Import slang-1.4.9 patch In-Reply-To: <200410251223.i9PCNg0X007452@email.zp.ua> References: <200410251223.i9PCNg0X007452@email.zp.ua> Message-ID: <20041025124109.6D8BC5080FD@mx.ktv.lt> On Mon, 25 Oct 2004 15:23:42 +0300 (EEST) "Andrew V. Samoilov" wrote: > > slsmg.c:76: `SLtt_Has_Alt_Charset' undeclared here (not in a function) > > slsmg.c:78: `SLtt_Use_Blink_For_ACS' undeclared here (not in a function) > > make: 1254-004 The error code from the last command is 1. > > Does AIX really not define unix, __unix or __unix__? Doesn't define, just checked. > Does it define __GO32__ ? No. > Well, if your first answer is Yes and second is NO, patch below can help you. > > Test it, please. Yes, it helps, thanks you! slang compiles w/o warnings. Regards, Nerijus From nerijus at users.sourceforge.net Mon Oct 25 13:58:12 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 25 Oct 2004 16:58:12 +0300 (EEST) Subject: Import slang-1.4.9 patch In-Reply-To: <20041025124109.6D8BC5080FD@mx.ktv.lt> References: <200410251223.i9PCNg0X007452@email.zp.ua> <20041025124109.6D8BC5080FD@mx.ktv.lt> Message-ID: <20041025135718.40D355084A0@mx.ktv.lt> On Mon, 25 Oct 2004 15:41:35 +0300 (EEST) Nerijus Baliunas wrote: > Yes, it helps, thanks you! slang compiles w/o warnings. But I get error when linking mc: ld: 0711-317 ERROR: Undefined symbol: .SLtt_get_terminfo ld: 0711-317 ERROR: Undefined symbol: .SLtt_tgetstr ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status It's because SLtt_get_terminfo() and SLtt_tgetstr() are defined in sldisply.c only if #ifdef __unix__. So the following patch is better: --- slang.h.orig Mon Oct 25 14:34:19 2004 +++ slang.h Mon Oct 25 16:46:14 2004 @@ -24,7 +24,7 @@ # endif #endif /* __watcomc__ */ -#if defined(unix) || defined(__unix) +#if defined(unix) || defined(__unix) || defined (_AIX) # ifndef __unix__ # define __unix__ 1 # endif But please add some comment so that it isn't removed after next slang update in the future. Regards, Nerijus From leonard at den.ottolander.nl Tue Oct 26 08:18:06 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 26 Oct 2004 10:18:06 +0200 Subject: extfs/iso9660.in Message-ID: <1098778685.4815.4.camel@athlon.localdomain> Hi, See attached patch for 2 fixes for iso9660.in. Also verified bpp to be correct. Can also be removed from the TODO list. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: iso9660.in.diff Type: text/x-patch Size: 654 bytes Desc: not available URL: From leonard at den.ottolander.nl Tue Oct 26 08:39:28 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 26 Oct 2004 10:39:28 +0200 Subject: extfs no more issues Message-ID: <1098779968.4815.9.camel@athlon.localdomain> Hi, I've been going through the shell scripts in extfs to check for quoting errors/omissions. Gone through all the perl scripts before and fixed all issues afaict. All should be properly quoted now, but it can't hurt if somebody else wants to go through them one more time to double check. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Tue Oct 26 08:25:44 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 26 Oct 2004 10:25:44 +0200 Subject: [PATCH]: menu doesn't appear on right info panel Message-ID: Hello, Attached is a patch to address this issue: http://mail.gnome.org/archives/mc-devel/2004-January/msg00007.html Changes introduced with rev. 1.22 of dialog.c can, under certain conditions, break the next widget selection alogrithm. In the past the routines `select_other_widget' and `dlg_select_widget' used to loop until they find a widget that would accept the focus i.e. one that accepts WIDGET_FOCUS messages. Currently it could happen that the new `do_select_widget' would finish without selecting a widget that accepts `WIDGET_FOCUS' messages. This is the source of the problem described in the link above. It is not immediatly clear, so I provide info from a debbuggin session: (gdb) p *h->current $3 = {x = 0, y = 0, cols = 125, lines = 1, options = 4, dlg_id = 0, next = 0x1009baf0, prev = 0x100a02b0, callback = 0x42d89a , mouse = 0x42d9d9 , parent = 0x1009bab0} (gdb) p *h->current->next $4 = {x = 0, y = 0, cols = 62, lines = 48, options = 0, dlg_id = 1, next = 0x100adab0, prev = 0x100a03a0, callback = 0x4417b9 , mouse = 0x441f03 , parent = 0x1009bab0} (gdb) p *h->current->next->next $5 = {x = 62, y = 0, cols = 63, lines = 48, options = 0, dlg_id = 2, next = 0x100a0360, prev = 0x1009baf0, callback = 0x422f57 , mouse = 0, parent = 0x1009bab0} (gdb) p *h->current->next->next->next $6 = {x = 0, y = 48, cols = 125, lines = 1, options = 0, dlg_id = 3, next = 0x1009fdd0, prev = 0x100adab0, callback = 0x456a74 , mouse = 0, parent = 0x1009bab0} (gdb) p *h->current->next->next->next->next $7 = {x = 2, y = 49, cols = 123, lines = 1, options = 20, dlg_id = 4, next = 0x100a0260, prev = 0x100a0360, callback = 0x40b598 , mouse = 0x458c91 , parent = 0x1009bab0} (gdb) p *h->current->next->next->next->next->next $8 = {x = 0, y = 49, cols = 2, lines = 1, options = 0, dlg_id = 5, next = 0x100a02b0, prev = 0x1009fdd0, callback = 0x456a74 , mouse = 0, parent = 0x1009bab0} (gdb) p *h->current->next->next->next->next->next->next $9 = {x = 0, y = 50, cols = 125, lines = 1, options = 2, dlg_id = 6, next = 0x100a03a0, prev = 0x100a0260, callback = 0x45a092 , mouse = 0x45a3f7 , parent = 0x1009bab0} (gdb) p *h->current->next->next->next->next->next->next->next $10 = {x = 0, y = 0, cols = 125, lines = 1, options = 4, dlg_id = 0, next = 0x1009baf0, prev = 0x100a02b0, callback = 0x42d89a , mouse = 0x42d9d9 , parent = 0x1009bab0} (gdb) Here is the list of all widgets of `midnight_dlg'. The current widget is the menubar and we want to select as the next widget the info panel, which doesn't accept WIDGET_FOCUS messages. In this case `do_select_widget' keeps walking the widget list starting at the info view up to the menbar (last in the list). There it decides that its job is done due to this check: while (h->current != w0) { Unfortunately it misses the left panel which would accept the WIDGET_FOCUS message, while the old routine would keep walking. -------------- next part -------------- Index: src/dialog.c =================================================================== RCS file: /cvsroot/mc/mc/src/dialog.c,v retrieving revision 1.26 diff -u -p -r1.26 dialog.c --- src/dialog.c 24 Sep 2004 22:22:35 -0000 1.26 +++ src/dialog.c 26 Oct 2004 10:01:36 -0000 @@ -427,10 +427,7 @@ do_select_widget (Dlg_head *h, Widget *w return; h->current = w; - while (h->current != w0) { - if (dlg_focus (h)) - break; - + while (!dlg_focus (h)) { switch (dir) { case SELECT_NEXT: h->current = h->current->next; From leonard at den.ottolander.nl Tue Oct 26 12:04:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 26 Oct 2004 14:04:50 +0200 Subject: Status of FTP password hiding patches Message-ID: <1098792290.4815.19.camel@athlon.localdomain> Hi, 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. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From juancri at TAGnet.org Tue Oct 26 12:22:48 2004 From: juancri at TAGnet.org (juancri at TAGnet.org) Date: Tue, 26 Oct 2004 09:22:48 -0300 Subject: ASP.NET Syntax Message-ID: Hi, I sent the ASP.NET Syntax file few days ago [aspx.syntax]. I think you could commit it to the CVS... only if you want, anyway :) [I sent it from juancri at juancri.com]. JcO From ptsekov at gmx.net Tue Oct 26 10:49:04 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 26 Oct 2004 12:49:04 +0200 Subject: Import slang-1.4.9 patch In-Reply-To: <20041025135718.40D355084A0@mx.ktv.lt> References: <200410251223.i9PCNg0X007452@email.zp.ua> <20041025124109.6D8BC5080FD@mx.ktv.lt> <20041025135718.40D355084A0@mx.ktv.lt> Message-ID: Hello, On Mon, 25 Oct 2004, Nerijus Baliunas wrote: > It's because SLtt_get_terminfo() and SLtt_tgetstr() are defined in > sldisply.c only if #ifdef __unix__. So the following patch is better: > > --- slang.h.orig Mon Oct 25 14:34:19 2004 > +++ slang.h Mon Oct 25 16:46:14 2004 > @@ -24,7 +24,7 @@ > # endif > #endif /* __watcomc__ */ > > -#if defined(unix) || defined(__unix) > +#if defined(unix) || defined(__unix) || defined (_AIX) > # ifndef __unix__ > # define __unix__ 1 > # endif > > But please add some comment so that it isn't removed after > next slang update in the future. Maybe you should raise the issue on the S-Lang dedicated mailing list. It would be much better if this is fixed by the upstream maintainer. From nerijus at users.sourceforge.net Tue Oct 26 13:38:30 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Tue, 26 Oct 2004 16:38:30 +0300 (EEST) Subject: Import slang-1.4.9 patch In-Reply-To: References: <200410251223.i9PCNg0X007452@email.zp.ua><20041025124109.6D8BC5080FD@mx.ktv.lt><20041025135718.40D355084A0@mx.ktv.lt> Message-ID: <20041026133852.7F87450840A@mx.ktv.lt> On Tue, 26 Oct 2004 12:49:04 +0200 Pavel Tsekov wrote: > Maybe you should raise the issue on the S-Lang dedicated mailing list. It > would be much better if this is fixed by the upstream maintainer. As I didn't have such problem with mc-4.6.0, I did some investigation. Included slang in mc-4.6.0 used extraconf.h: diff -ur mc-4.6.0/slang/.deps/sldisply.Po mc-2004-10-22-21/slang/.deps/sldisply.Po --- mc-4.6.0/slang/.deps/sldisply.Po 2004-10-26 16:14:32.000000000 +0300 +++ mc-2004-10-22-21/slang/.deps/sldisply.Po 2004-10-25 16:48:59.000000000 +0300 @@ -1,5 +1,5 @@ sldisply.o : \ - sldisply.c include/slinclud.h ../config.h ../extraconf.h \ + sldisply.c include/slinclud.h ../config.h \ ... @@ -36,7 +36,6 @@ sldisply.c : include/slinclud.h : ../config.h : -../extraconf.h : Now mc does not have extraconf.h anymore. And in 4.6.0 it contained: /* This file is included directly from config.h. Don't include it from any other files. The only code that belongs here is preprocessor directives that: 1) change the configuration setting defined in config.h if they there is a conflict between them. 2) define symbols that fully depend on those in config.h to eliminate the need to embed this logic into configure.in. */ #ifdef HAVE_LIBPT # define HAVE_GRANTPT #endif ... #ifndef NATIVE_WIN32 /* some Unices do not define this, and slang requires it: */ #ifndef unix # define unix #endif #endif Regards, Nerijus From vda at port.imtp.ilyichevsk.odessa.ua Mon Oct 25 15:36:49 2004 From: vda at port.imtp.ilyichevsk.odessa.ua (Denis Vlasenko) Date: Mon, 25 Oct 2004 18:36:49 +0300 Subject: Fwd: [PATCH] make old escmode key timeout configurable Message-ID: <200410251836.49794.vda@port.imtp.ilyichevsk.odessa.ua> Forwarding to mc-devel per suggestion of Leonard den Ottolander ---------- Forwarded Message ---------- Subject: [PATCH] make old escmode key timeout configurable Date: Saturday 23 October 2004 21:21 From: Denis Vlasenko Hi, My memories are vague but I think that mc was the very first Linux app I built from source, so this is a bit nostalgic now :) I used old_escmode. I did not like 1 second delay and hacked ESCMODE_TIMEOUT to 10000 usecs. I knew zilch about patches and the process of submitting, so that change was sitting there in my mc-4.5.51 for years. Now time has come to compile new mc (for uclibc), and here is the patch against 4.6.0. Usage: $ mc - as usual $ KEYBOARD_KEY_TIMEOUT_US=25000 mc - ESC acts way faster than before, annoying 1-second pause is gone (pause is there but 25 msec only) Tested. Please apply. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: mc_key_timeout.diff Type: text/x-diff Size: 952 bytes Desc: not available URL: From ossi at kde.org Tue Oct 26 14:56:03 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Tue, 26 Oct 2004 16:56:03 +0200 Subject: extfs/iso9660.in In-Reply-To: <1098778685.4815.4.camel@athlon.localdomain> References: <1098778685.4815.4.camel@athlon.localdomain> Message-ID: <20041026145603.GB11122@ugly.local> On Tue, Oct 26, 2004 at 10:18:06AM +0200, Leonard den Ottolander wrote: > See attached patch for 2 fixes for iso9660.in. > what exactly is the second hunk (which is inside an awk script) supposed to do? -- 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 Oct 26 15:48:34 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 26 Oct 2004 17:48:34 +0200 Subject: extfs/iso9660.in In-Reply-To: <20041026145603.GB11122@ugly.local> References: <1098778685.4815.4.camel@athlon.localdomain> <20041026145603.GB11122@ugly.local> Message-ID: <1098805714.4815.29.camel@athlon.localdomain> Hello Oswald, On Tue, 2004-10-26 at 16:56, Oswald Buddenhagen wrote: > what exactly is the second hunk (which is inside an awk script) supposed > to do? The extra 'x's are a bashism. I wasn't sure if they would be useful here. I suppose you can just ignore that hunk. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ossi at kde.org Tue Oct 26 18:04:16 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Tue, 26 Oct 2004 20:04:16 +0200 Subject: extfs/iso9660.in In-Reply-To: <1098805714.4815.29.camel@athlon.localdomain> References: <1098778685.4815.4.camel@athlon.localdomain> <20041026145603.GB11122@ugly.local> <1098805714.4815.29.camel@athlon.localdomain> Message-ID: <20041026180416.GB14669@ugly.local> On Tue, Oct 26, 2004 at 05:48:34PM +0200, Leonard den Ottolander wrote: > On Tue, 2004-10-26 at 16:56, Oswald Buddenhagen wrote: > > what exactly is the second hunk (which is inside an awk script) supposed > > to do? > > The extra 'x's are a bashism. I wasn't sure if they would be useful > here. I suppose you can just ignore that hunk. > it's more than that - it is actually outright wrong. awk does not expand variables in quoted strings. but this code seems strange to me anyway ... what is this construct supposed to do? it is certainly not equal to 'if ($11 != "") {'. -- 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 Oct 26 18:49:14 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 26 Oct 2004 20:49:14 +0200 Subject: extfs/iso9660.in In-Reply-To: <20041026180416.GB14669@ugly.local> References: <1098778685.4815.4.camel@athlon.localdomain> <20041026145603.GB11122@ugly.local> <1098805714.4815.29.camel@athlon.localdomain> <20041026180416.GB14669@ugly.local> Message-ID: <1098816554.4815.37.camel@athlon.localdomain> Hello Oswald, On Tue, 2004-10-26 at 20:04, Oswald Buddenhagen wrote: > it's more than that - it is actually outright wrong. awk does not expand > variables in quoted strings. Quite possible. Posting this patch seemed the easiest way to get an answer ;-) . > but this code seems strange to me anyway ... what is this construct > supposed to do? it is certainly not equal to 'if ($11 != "") {'. I thought it meant something like that, but actually I don't know awk. It's just that nobody seems to pick up the job of auditing those scripts, so it seemed easier to just put up something for discussion and be proven wrong about one "catch" too many than to wait for someone to come up with a correct solution. Of course I should have verified it myself, but I just didn't feel like it :-p . I suppose just applying the first hunk suffices. If you feel like interpreting that awk code you're welcome :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Wed Oct 27 07:25:26 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 27 Oct 2004 09:25:26 +0200 Subject: [PATCH] completion_matches(): kill duplicate entries Message-ID: Hello, A one liner that fixes duplicate completion matches if there are more than two matches available. This is not a new bug - it was in 4.6.0 and mayber earlier versions (haven't checked though). To reproduce the bug put the same path in PATH three or more times. Try to complete an executable that you know resides in that path. -------------- next part -------------- Index: complete.c =================================================================== RCS file: /cvsroot/mc/mc/src/complete.c,v retrieving revision 1.52 diff -u -p -r1.52 complete.c --- complete.c 23 Oct 2004 07:12:39 -0000 1.52 +++ complete.c 27 Oct 2004 08:53:38 -0000 @@ -575,6 +575,7 @@ completion_matches (char *text, Completi j++; if (j > matches) break; + continue; /* Look for a run of equal strings */ } else if (low > si) low = si; if (i + 1 != j) /* So there's some gap */ From leonard at den.ottolander.nl Wed Oct 27 12:37:37 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 14:37:37 +0200 Subject: Fixed patch: extfs/iso9660.in In-Reply-To: <1098816554.4815.37.camel@athlon.localdomain> References: <1098778685.4815.4.camel@athlon.localdomain> <20041026145603.GB11122@ugly.local> <1098805714.4815.29.camel@athlon.localdomain> <20041026180416.GB14669@ugly.local> <1098816554.4815.37.camel@athlon.localdomain> Message-ID: <1098880657.4812.2.camel@athlon.localdomain> Hi, Ok, for clarity's sake I fixed the patch by dropping the second hunk. Please commit this one hunk patch. Anybody feels like double checking the shell scripts in vfs/extfs? Perl scripts should all be fine. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: iso9660.in.diff Type: text/x-patch Size: 476 bytes Desc: not available URL: From me at pavelsh.pp.ru Wed Oct 27 12:54:51 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 18:54:51 +0600 Subject: [patch] TODO for 4.6.1: ./file in tar archive In-Reply-To: <1098298314.4901.67.camel@athlon.localdomain> References: <415C47F2.9010102@gmx.de> <1098298314.4901.67.camel@athlon.localdomain> Message-ID: <798249418.20041027185451@pavelsh.pp.ru> Hello Leonard, Thursday, October 21, 2004, 12:51:55 AM, you wrote: >> this patch fixes the second TODO item for 4.6.1. LdO> I wasn't aware of the fact that this patch had been committed as I LdO> thought we were still discussing where this issue should be fixed. LdO> If we stay with this fix, does the attached patch make any sense? The LdO> q++ is just geekness, but I'm wondering if the canonicalize_pathname is LdO> actually useful here, or counterproductive, as we are indirectly working LdO> on current_file_name. Committed. Thanks. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Wed Oct 27 12:58:41 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 18:58:41 +0600 Subject: Fixed patch: extfs/iso9660.in In-Reply-To: <1098880657.4812.2.camel@athlon.localdomain> References: <1098778685.4815.4.camel@athlon.localdomain> <20041026145603.GB11122@ugly.local> <1098805714.4815.29.camel@athlon.localdomain> <20041026180416.GB14669@ugly.local> <1098816554.4815.37.camel@athlon.localdomain> <1098880657.4812.2.camel@athlon.localdomain> Message-ID: <721637833.20041027185841@pavelsh.pp.ru> Hello Leonard, Wednesday, October 27, 2004, 6:37:37 PM, you wrote: LdO> Ok, for clarity's sake I fixed the patch by dropping the second hunk. LdO> Please commit this one hunk patch. LdO> Anybody feels like double checking the shell scripts in vfs/extfs? Perl LdO> scripts should all be fine. Committed. Thanks! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Wed Oct 27 13:00:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 15:00:43 +0200 Subject: [PATCH]: Add support for changing drives in Cygwin - second try In-Reply-To: References: <200410081126.i98BQmMA023498@email.zp.ua> Message-ID: <1098882043.4812.4.camel@athlon.localdomain> Hello Pavel, On Fri, 2004-10-08 at 12:09, Pavel Tsekov wrote: > On Fri, 8 Oct 2004, Andrew V. Samoilov wrote: > > I have no cygwin, but I reviewed this patch. > > Why you don't use glib memory manipulation functions and gettext? > > Also it is possible to use MSG_ERROR intead of hardcoded "Error" with message(). > > I'll update the patch as you suggest. We haven't seen an updated patch yet. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nerijus at users.sourceforge.net Wed Oct 27 13:08:58 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 27 Oct 2004 16:08:58 +0300 (EEST) Subject: Import slang-1.4.9 patch In-Reply-To: <166565075.20041024042253@mail.ru> References: <166565075.20041024042253@mail.ru> Message-ID: <20041027130848.5F9E450802E@mx.ktv.lt> On Sun, 24 Oct 2004 04:22:53 +0600 pavelsh wrote: > Please, check my patch (import libslang-1.4.9 into mcslang). > > It's working fine for me. > > P.S.:FreeBSD-5.2.1 Working fine on AIX 5.1 too (with defining unix, see the end of the thread - but this problem was with earlier slang also, so it's not a regression). Nerijus From ptsekov at gmx.net Wed Oct 27 11:28:27 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 27 Oct 2004 13:28:27 +0200 Subject: [PATCH]: Add support for changing drives in Cygwin - second try In-Reply-To: <1098882043.4812.4.camel@athlon.localdomain> References: <200410081126.i98BQmMA023498@email.zp.ua> <1098882043.4812.4.camel@athlon.localdomain> Message-ID: On Wed, 27 Oct 2004, Leonard den Ottolander wrote: > Hello Pavel, > > On Fri, 2004-10-08 at 12:09, Pavel Tsekov wrote: > > On Fri, 8 Oct 2004, Andrew V. Samoilov wrote: > > > I have no cygwin, but I reviewed this patch. > > > Why you don't use glib memory manipulation functions and gettext? > > > Also it is possible to use MSG_ERROR intead of hardcoded "Error" with message(). > > > > I'll update the patch as you suggest. > > We haven't seen an updated patch yet. True and quite unfortunate. I guess it won't get into 4.6.1. If you want to relase - then just ignore this patch. As time allows I'll update it properly and will resubmit. Please, consider the other small patches that I posted though. Also the one with the escape sequences generated by gnome-terminal. From me at pavelsh.pp.ru Wed Oct 27 13:27:18 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 19:27:18 +0600 Subject: aspx syntax file In-Reply-To: References: Message-ID: <397391839.20041027192718@pavelsh.pp.ru> Hello Juan, Saturday, October 23, 2004, 1:54:16 AM, you wrote: JCO> This is a new Syntax file for ASP.NET. This includes: JCO> .aspx Web Forms JCO> .ashx Web Handlers JCO> .asmx Web Services JCO> .ascx Web User Control JCO> .asax Web Application Global Class JCO> I think it's complete. It does not highlight C#/VB.NET code within a JCO> page... as HTML does not highlight PHP code on Web pages :) JCO> I added these two lines to my Syntax file: JCO> file ..\*\\.(asax|aspx|ascx|asmx|ashx)$ ASPX\sFile JCO> include aspx.syntax Committed. Thanks. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From ptsekov at gmx.net Wed Oct 27 11:32:44 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 27 Oct 2004 13:32:44 +0200 Subject: Import slang-1.4.9 patch In-Reply-To: <20041027130848.5F9E450802E@mx.ktv.lt> References: <166565075.20041024042253@mail.ru> <20041027130848.5F9E450802E@mx.ktv.lt> Message-ID: Hello, On Wed, 27 Oct 2004, Nerijus Baliunas wrote: > On Sun, 24 Oct 2004 04:22:53 +0600 pavelsh wrote: > > > Please, check my patch (import libslang-1.4.9 into mcslang). > > > > It's working fine for me. > > > > P.S.:FreeBSD-5.2.1 > > Working fine on AIX 5.1 too (with defining unix, see the end of the thread - > but this problem was with earlier slang also, so it's not a regression). I've tested on Cygwin and it seems ok. I didn't perform an exhaustive testing - just the usual things that I do with MC. Btw if you update slang would you care to fix this: http://mail.gnome.org/archives/mc-devel/2004-October/msg00050.html From me at pavelsh.pp.ru Wed Oct 27 13:45:39 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 19:45:39 +0600 Subject: patch: mcview with growing buffers In-Reply-To: <41790941.3030200@gmx.de> References: <41790941.3030200@gmx.de> Message-ID: <1964585854.20041027194539@pavelsh.pp.ru> Hello Roland, Friday, October 22, 2004, 7:21:05 PM, you wrote: RI> this patch is quite complex. It fixes these issues: RI> - WView contained a struct stat that was only partly used (and mostly RI> abused for _not_ storing file information). RI> - Error checking using the growing buffer has been added. RI> - Some variables need an adjustment function called after they are RI> assigned a new value. This is explicitly documented. RI> - Some variables have been renamed. For example, char *data is now RI> accompanied by size_t datasize. A similar change has been applied to the RI> mmap functions: The variable bytes_read has been used inconsistently and RI> has been replaced by mmappedsize. RI> - The function get_byte has become much simpler after factoring out the RI> growing buffer handling into a separate function. Please fill out: [ ] ok to commit [X] needs review [ ] rejected It's candidate for 4.6.2 -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Wed Oct 27 14:02:34 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 20:02:34 +0600 Subject: extfs trpm In-Reply-To: <1098226050.4811.163.camel@athlon.localdomain> References: <1098225889.4811.159.camel@athlon.localdomain> <1098226050.4811.163.camel@athlon.localdomain> Message-ID: <1189918045.20041027200234@pavelsh.pp.ru> Hello Leonard, Wednesday, October 20, 2004, 4:47:31 AM, you wrote: >> Attached you find the proposed fixes to trpm. The SEDCMD that is used in >> rpm can not be used for the rpms file system. This should fix all the >> quoting. Increased the "file" size for UNINSTALL to 40 as the message >> "uninstalling rpm" was missing the last char. >> >> Please check for omissions and errors before committing ;) . LdO> Always handy to actually attach the patch :-) . Here it is. Committed. Thanks. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Wed Oct 27 14:05:02 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 20:05:02 +0600 Subject: building on AIX In-Reply-To: <417AA819.8070302@gmx.de> References: <20041023143255.0CD41508412@mx.ktv.lt> <417AA819.8070302@gmx.de> Message-ID: <383643403.20041027200502@pavelsh.pp.ru> Hello Roland, Sunday, October 24, 2004, 12:51:05 AM, you wrote: >> ftpfs.c: In function `ftpfs_initconn': >> ftpfs.c:889: warning: passing arg 3 of `ngetsockname' from incompatible pointer type >> ftpfs.c:912: warning: passing arg 3 of `ngetsockname' from incompatible pointer type >> ftpfs.c: In function `ftpfs_open_data_connection': >> ftpfs.c:957: warning: passing arg 3 of `naccept' from incompatible pointer type RI> Thanks for reporting these. RI> The patch is to add an AC_CHECK_TYPE(socklen_t, size_t) to configure.ac RI> and then replace the types in all the wrong declarations with socklen_t. RI> Concerning socklen_t.patch: [x] ok to commit [ ] needs review [ ] rejected With fallback to int. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Wed Oct 27 14:11:02 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 16:11:02 +0200 Subject: extfs trpm In-Reply-To: <4179FE3C.2040206@gmx.de> References: <1098225889.4811.159.camel@athlon.localdomain> <1098226050.4811.163.camel@athlon.localdomain> <4179FE3C.2040206@gmx.de> Message-ID: <1098886262.4812.8.camel@athlon.localdomain> Hello Roland, On Sat, 2004-10-23 at 08:46, Roland Illig wrote: > One omission is that you did not properly quote filenames that might > start with a hyphen. Imagine a weird rpm called -package-4.5.rpm. This is rather academical and rpm names starting with a hyphen will break a lot of other tools, so the chance they are being used is practically zero. And if they are used this will only break output and not cause "bad things". Please commit the original patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Wed Oct 27 14:13:26 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 20:13:26 +0600 Subject: Import slang-1.4.9 patch In-Reply-To: <20041025135718.40D355084A0@mx.ktv.lt> References: <200410251223.i9PCNg0X007452@email.zp.ua> <20041025124109.6D8BC5080FD@mx.ktv.lt> <20041025135718.40D355084A0@mx.ktv.lt> Message-ID: <412018759.20041027201326@pavelsh.pp.ru> Hello Nerijus, Monday, October 25, 2004, 7:58:12 PM, you wrote: NB> --- slang.h.orig Mon Oct 25 14:34:19 2004 NB> +++ slang.h Mon Oct 25 16:46:14 2004 NB> @@ -24,7 +24,7 @@ NB> # endif NB> #endif /* __watcomc__ */ NB> -#if defined(unix) || defined(__unix) NB> +#if defined(unix) || defined(__unix) || defined (_AIX) NB> # ifndef __unix__ NB> # define __unix__ 1 NB> # endif Committed. Thanks. NB> But please add some comment so that it isn't removed after NB> next slang update in the future. Ok. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Wed Oct 27 14:27:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 16:27:43 +0200 Subject: extfs trpm In-Reply-To: <1098886262.4812.8.camel@athlon.localdomain> References: <1098225889.4811.159.camel@athlon.localdomain> <1098226050.4811.163.camel@athlon.localdomain> <4179FE3C.2040206@gmx.de> <1098886262.4812.8.camel@athlon.localdomain> Message-ID: <1098887262.4812.16.camel@athlon.localdomain> Hi, I wrote: > This is rather academical and rpm names starting with a hyphen will > break a lot of other tools, so the chance they are being used is > practically zero. And if they are used this will only break output and > not cause "bad things". There is one occurrence of rpm -e "$1". I don't think this is exploitable, but I've decided to add -- before all "$1"s in rpm calls. I can't hurt. See attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: trpm.diff Type: text/x-patch Size: 10436 bytes Desc: not available URL: From me at pavelsh.pp.ru Wed Oct 27 14:33:24 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 20:33:24 +0600 Subject: Import slang-1.4.9 patch - fixed for AIX Message-ID: <10210577753.20041027203324@pavelsh.pp.ru> Hello mc-devel, http://pavelsh.pp.ru/slang.patch Please, checkit -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Wed Oct 27 14:35:41 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 16:35:41 +0200 Subject: extfs/trpm rpm name starting with hyphen Message-ID: <1098887741.4812.20.camel@athlon.localdomain> Hi, Ok. As it won't hurt here is a patch that fixes the issue with rpm names starting with a hyphen. Put -- before "$1" to stop argument parsing. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: trpm.diff Type: text/x-patch Size: 9857 bytes Desc: not available URL: From me at pavelsh.pp.ru Wed Oct 27 14:42:03 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 27 Oct 2004 20:42:03 +0600 Subject: extfs/trpm rpm name starting with hyphen In-Reply-To: <1098887741.4812.20.camel@athlon.localdomain> References: <1098887741.4812.20.camel@athlon.localdomain> Message-ID: <132593802.20041027204203@pavelsh.pp.ru> Hello Leonard, Wednesday, October 27, 2004, 8:35:41 PM, you wrote: LdO> Ok. As it won't hurt here is a patch that fixes the issue with rpm names LdO> starting with a hyphen. Put -- before "$1" to stop argument parsing. Committed. Thanks -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Wed Oct 27 14:44:36 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 16:44:36 +0200 Subject: Occam and php.smarty syntax Message-ID: <1098888276.4812.29.camel@athlon.localdomain> Hello, I've just been discussing the possible inclusion of the occam and php.smarty syntax. Pavel Shirshov believes these languages are not widespread enough to justify inclusion. Any thoughts? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nerijus at users.sourceforge.net Wed Oct 27 15:20:37 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 27 Oct 2004 18:20:37 +0300 (EEST) Subject: Import slang-1.4.9 patch - fixed for AIX In-Reply-To: <10210577753.20041027203324@pavelsh.pp.ru> References: <10210577753.20041027203324@pavelsh.pp.ru> Message-ID: <20041027151929.DD54F508337@mx.ktv.lt> On Wed, 27 Oct 2004 20:33:24 +0600 "Pavel Shirshov (pchel)" wrote: > http://pavelsh.pp.ru/slang.patch It's the same as your earlier patch, the only difference is it includes ChangeLog.diff, which does not apply, and one change in sldisply.c, but with #if 0. Nothing added for AIX. Regards, Nerijus From nerijus at users.sourceforge.net Wed Oct 27 15:36:33 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 27 Oct 2004 18:36:33 +0300 (EEST) Subject: Import slang-1.4.9 patch - fixed for AIX In-Reply-To: <10210577753.20041027203324@pavelsh.pp.ru> References: <10210577753.20041027203324@pavelsh.pp.ru> Message-ID: <20041027153523.906AA50860B@mx.ktv.lt> On Wed, 27 Oct 2004 20:33:24 +0600 "Pavel Shirshov (pchel)" wrote: > http://pavelsh.pp.ru/slang.patch > > Please, checkit Ah, you already applied a fix for AIX to cvs, so it is not needed in this patch. But your patch changes tabs to spaces in a diff for Changelog after my name, it's minor of course, but probably not needed ;-) Nerijus From jnovy at redhat.com Wed Oct 27 16:20:41 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 27 Oct 2004 18:20:41 +0200 Subject: Status of FTP password hiding patches In-Reply-To: <1098792290.4815.19.camel@athlon.localdomain> References: <1098792290.4815.19.camel@athlon.localdomain> Message-ID: <1098894040.25673.24.camel@localhost.localdomain> 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. Hi, I fixed the possible memory leak regarding label_string found by Andrew V. Samoilov, see bug 131088 in Red Hat bugzilla. To test this patch, create an user "test" for example, set his password to "testpass", change your cwd by "cd /#ftp:test:testpass at localhost" and: - try to upload a file to this directory and note the password is removed. Copy, error and other dialogs display "/#ftp:test at localhost" - try to add the new ftp directory to directory hotlist, password will be also removed - try to find any dialog where the password is displayed I tested it and was unable to find any dialog that still shows a password in it. The patch is cleanly applicable to 20th Oct mc CVS snapshot. HTH, 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: 10806 bytes Desc: not available URL: From jnovy at redhat.com Wed Oct 27 16:35:50 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 27 Oct 2004 18:35:50 +0200 Subject: additional formats for "play" and "mikmod" to mc.ext.in Message-ID: <1098894950.25673.32.camel@localhost.localdomain> Hi, I decided propose an addition of a few sound formats that "play" and "mikmod" utility knows but they are not handled in recent mc.ext.in. cheers, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-soundext.patch Type: text/x-patch Size: 660 bytes Desc: not available URL: From roland.illig at gmx.de Wed Oct 27 16:42:39 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 27 Oct 2004 18:42:39 +0200 Subject: extfs/iso9660.in Message-ID: <417FCFFF.6060509@gmx.de> Hi, my isoinfo command output some ugly numbers before the file names. Example: roland at wwid:/tmp > /tmp/mc/installed/debug/share/mc/extfs/iso9660 list mc-test.iso | tail -n 2 -r--r--r-- 1 root root 46 Feb 24 2004 wip/unrealtournament-server/files/ASU/umodasu/CVS/Repository -r--r--r-- 1 root root 52 Feb 24 2004 wip/unrealtournament-server/files/ASU/umodasu/CVS/Root roland at wwid:/tmp > /usr/share/mc/extfs/iso9660 list mc-test.iso | tail -n 2 -r--r--r-- 1 root root 46 Feb 24 2004 wip/unrealtournament-server/files/ASU/umodasu/CVS/[ 59819 00] Repository -r--r--r-- 1 root root 52 Feb 24 2004 wip/unrealtournament-server/files/ASU/umodasu/CVS/[ 57962 00] Root Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: iso9660.in-listing.patch Type: text/x-patch Size: 541 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Oct 27 19:07:21 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 21:07:21 +0200 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: <1098904040.4812.32.camel@athlon.localdomain> On Wed, 2004-10-27 at 18:20, Jindrich Novy wrote: > I fixed the possible memory leak regarding label_string found by Andrew > V. Samoilov, see bug 131088 in Red Hat bugzilla. What happened to +++ mc-4.6.1-20040906/src/util.c 2004-09-10 09:53:45.317252216 +0200 @@ -510,6 +526,7 @@ {"/#mc:", 5}, {"ftp://", 6}, {"/#smb:", 6}, + {"/#sh:", 5}, }; char *at, *inner_colon, *dir; size_t i; ? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Wed Oct 27 19:17:06 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 27 Oct 2004 21:17:06 +0200 Subject: patch: mcview with growing buffers In-Reply-To: <1964585854.20041027194539@pavelsh.pp.ru> References: <41790941.3030200@gmx.de> <1964585854.20041027194539@pavelsh.pp.ru> Message-ID: <417FF432.7080403@gmx.de> Pavel Shirshov (pchel) wrote: > Please fill out: > [ ] ok to commit > [X] needs review > [ ] rejected > > It's candidate for 4.6.2 I forgot to mention that this patch fixes the bug you discovered when opening a file in patchfs which could not be found. Roland From leonard at den.ottolander.nl Wed Oct 27 19:18:18 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 21:18:18 +0200 Subject: extfs/iso9660.in In-Reply-To: <417FCFFF.6060509@gmx.de> References: <417FCFFF.6060509@gmx.de> Message-ID: <1098904697.4812.41.camel@athlon.localdomain> Hi Roland, On Wed, 2004-10-27 at 18:42, Roland Illig wrote: > +$ISOINFO -l -i "$1" | sed -e 's,\[[ ]*[0-9][0-9]*[ ]*[0-9][0-9]*\][ ]*,,' | @AWK@ ' Wouldn't it be better to fix this inside the awk script? Or parse the whole thing with sed? It seems a bit redundant to use both awk and sed... Otherwise you might want to replace the above with this (sorry for the line wrap): +$ISOINFO -l -i "$1" | sed -e 's,\[[ ]*[0-9]+[ ]+[0-9]+\][ ]*,,' | @AWK@ ' Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Wed Oct 27 19:43:06 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 27 Oct 2004 21:43:06 +0200 Subject: extfs/iso9660.in In-Reply-To: <1098904697.4812.41.camel@athlon.localdomain> References: <417FCFFF.6060509@gmx.de> <1098904697.4812.41.camel@athlon.localdomain> Message-ID: <417FFA4A.1000702@gmx.de> Leonard den Ottolander wrote: > Hi Roland, > > On Wed, 2004-10-27 at 18:42, Roland Illig wrote: > >>+$ISOINFO -l -i "$1" | sed -e 's,\[[ ]*[0-9][0-9]*[ ]*[0-9][0-9]*\][ ]*,,' | @AWK@ ' > > > Wouldn't it be better to fix this inside the awk script? Or parse the > whole thing with sed? It seems a bit redundant to use both awk and > sed... > > Otherwise you might want to replace the above with this (sorry for the > line wrap): > +$ISOINFO -l -i "$1" | sed -e 's,\[[ ]*[0-9]+[ ]+[0-9]+\][ ]*,,' | @AWK@ No, that's not portable. Of course, the GNU sed can do it, but the Solaris sed doesn't. The SUSv3 only requires the *, not the +. http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html section 9.3.3 Roland From leonard at den.ottolander.nl Wed Oct 27 20:16:12 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 22:16:12 +0200 Subject: extfs/iso9660.in In-Reply-To: <417FFA4A.1000702@gmx.de> References: <417FCFFF.6060509@gmx.de> <1098904697.4812.41.camel@athlon.localdomain> <417FFA4A.1000702@gmx.de> Message-ID: <1098908171.4812.45.camel@athlon.localdomain> Hi Roland, On Wed, 2004-10-27 at 21:43, Roland Illig wrote: > > Wouldn't it be better to fix this inside the awk script? > > +$ISOINFO -l -i "$1" | sed -e 's,\[[ ]*[0-9]+[ ]+[0-9]+\][ ]*,,' | @AWK@ > > No, that's not portable. Of course, the GNU sed can do it, but the > Solaris sed doesn't. The SUSv3 only requires the *, not the +. Aha. Ok. Still leaves the remark about fixing this in the awk script. Can you fix it there? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Oct 27 21:58:45 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 27 Oct 2004 23:58:45 +0200 Subject: extfs/iso9660.in In-Reply-To: <417FCFFF.6060509@gmx.de> References: <417FCFFF.6060509@gmx.de> Message-ID: <1098914324.4812.48.camel@athlon.localdomain> Hi Roland, On Wed, 2004-10-27 at 18:42, Roland Illig wrote: > -$ISOINFO -l -i "$1" | @AWK@ ' > +$ISOINFO -l -i "$1" | sed -e 's,\[[ ]*[0-9][0-9]*[ ]*[0-9][0-9]*\][ ]*,,' | @AWK@ ' Try attached patch instead. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: iso9660.in.diff Type: text/x-patch Size: 336 bytes Desc: not available URL: From me at pavelsh.pp.ru Thu Oct 28 06:17:00 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 28 Oct 2004 12:17:00 +0600 Subject: additional formats for "play" and "mikmod" to mc.ext.in In-Reply-To: <1098894950.25673.32.camel@localhost.localdomain> References: <1098894950.25673.32.camel@localhost.localdomain> Message-ID: <17710451373.20041028121700@pavelsh.pp.ru> Hello Jindrich, Wednesday, October 27, 2004, 10:35:50 PM, you wrote: JN> I decided propose an addition of a few sound formats that "play" and JN> "mikmod" utility knows but they are not handled in recent mc.ext.in. Committed. Thanks. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Thu Oct 28 06:32:28 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 28 Oct 2004 12:32:28 +0600 Subject: Import slang-1.4.9 patch - fixed for AIX In-Reply-To: <20041027153523.85DC25085CC@mx.ktv.lt> References: <10210577753.20041027203324@pavelsh.pp.ru> <20041027153523.85DC25085CC@mx.ktv.lt> Message-ID: <903294069.20041028123228@pavelsh.pp.ru> Hello Nerijus, Wednesday, October 27, 2004, 9:36:33 PM, you wrote: >> http://pavelsh.pp.ru/slang.patch >> >> Please, checkit NB> Ah, you already applied a fix for AIX to cvs, so it is not needed in this patch. Yes. NB> But your patch changes tabs to spaces in a diff for Changelog after NB> my name, it's minor of course, but probably not needed ;-) Fixed. Thanks! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From jnovy at centrum.cz Thu Oct 28 07:10:20 2004 From: jnovy at centrum.cz (Jindrich Novy) Date: Thu, 28 Oct 2004 09:10:20 +0200 Subject: Status of FTP password hiding patches Message-ID: <20041028071031Z1622392-15010+30407@mail.centrum.cz> Hi Leonard, What happened to >+++ mc-4.6.1-20040906/src/util.c 2004-09-10 09:53:45.317252216 +0200 >@@ -510,6 +526,7 @@ > {"/#mc:", 5}, > {"ftp://";, 6}, > {"/#smb:", 6}, >+ {"/#sh:", 5}, > }; > char *at, *inner_colon, *dir; > size_t i; >? because this part is already applied, please see http://mail.gnome.org/archives/mc-devel/2004-October/msg00038.html Jindrich From leonard at den.ottolander.nl Thu Oct 28 10:58:24 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 12:58:24 +0200 Subject: Status of FTP password hiding patches In-Reply-To: <20041028071031Z1622392-15010+30407@mail.centrum.cz> References: <20041028071031Z1622392-15010+30407@mail.centrum.cz> Message-ID: <1098961104.4813.4.camel@athlon.localdomain> Hello Jindrich, On Thu, 2004-10-28 at 09:10, Jindrich Novy wrote: > >+ {"/#sh:", 5}, > because this part is already applied, please see > http://mail.gnome.org/archives/mc-devel/2004-October/msg00038.html I see. I forgot to check the source as I thought none of the proposed patches had been applied yet. Do you have commit access? Or did someone else commit it? Lately most commits are reported back to the list if they have been discussed here (at least pchel does so) so this is why I hadn't noticed it had been committed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Oct 28 11:13:53 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 13:13:53 +0200 Subject: extfs/iso9660.in In-Reply-To: <1098914324.4812.48.camel@athlon.localdomain> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> Message-ID: <1098962032.4813.9.camel@athlon.localdomain> Hi, I wrote: > - irx = "^. *[0-9]+. "; > + irx = "^\[ *[0-9]+[ ]+[0-9]+\] "; Brackets around the space in the middle are unnecessary. Use + irx = "^\[ *[0-9]+ +[0-9]+\] "; instead. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Thu Oct 28 11:17:39 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 28 Oct 2004 14:17:39 +0300 (EEST) Subject: fish issue Message-ID: <200410281117.i9SBHd1V036469@email.zp.ua> Hello, -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fish.c.patch URL: From me at pavelsh.pp.ru Thu Oct 28 11:22:52 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 28 Oct 2004 17:22:52 +0600 Subject: fish issue In-Reply-To: <200410281117.i9SBHd1V036469@email.zp.ua> References: <200410281117.i9SBHd1V036469@email.zp.ua> Message-ID: <1475129750.20041028172252@pavelsh.pp.ru> Hello Andrew, Thursday, October 28, 2004, 5:17:39 PM, you wrote: AVS> Hello, > * fish.c (fish_open_archive_int): Fix missed "%s". Committed. Thx! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Thu Oct 28 11:47:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 13:47:27 +0200 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: References: Message-ID: <1098964046.4813.22.camel@athlon.localdomain> Hello Pavel, On Tue, 2004-10-26 at 10:25, Pavel Tsekov wrote: > - while (h->current != w0) { > - if (dlg_focus (h)) > - break; > - > + while (!dlg_focus (h)) { Don't we need + if (h->current == w0) + break; as well? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Thu Oct 28 10:55:21 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 28 Oct 2004 12:55:21 +0200 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: <1098964046.4813.22.camel@athlon.localdomain> References: <1098964046.4813.22.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: > > - while (h->current != w0) { > > - if (dlg_focus (h)) > > - break; > > - > > + while (!dlg_focus (h)) { > > Don't we need > > + if (h->current == w0) > + break; > > as well? As far as I understand the code - no we don't need it. The old code acted this way. It looks hard for a widget that accepts WIDGET_FOCUS messages. If we introduce the check that you suggest, you'll end up exactly in the same situation that this patch is trying to remedy. 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. In any case I think the current code is incomplete (wrong) and I consider it a regression. Anyway, if there is a doubt about this patch maybe we should ask someone with more knowledge of the code for advice. From roland.illig at gmx.de Thu Oct 28 13:00:29 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 28 Oct 2004 15:00:29 +0200 Subject: extfs/iso9660.in In-Reply-To: <1098962032.4813.9.camel@athlon.localdomain> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> <1098962032.4813.9.camel@athlon.localdomain> Message-ID: <4180ED6D.8070102@gmx.de> Leonard den Ottolander wrote: > Hi, > > I wrote: > >>- irx = "^. *[0-9]+. "; >>+ irx = "^\[ *[0-9]+[ ]+[0-9]+\] "; > > > Brackets around the space in the middle are unnecessary. Use > > + irx = "^\[ *[0-9]+ +[0-9]+\] "; > > instead. Please read the awk manual ("info gawk") before committing untested code which does not work. > - irx = "^\[ *[0-9]+ +[0-9]+\] "; > + irx = "^\\[ *[0-9]+ +[0-9]+\\] "; Roland From roland.illig at gmx.de Thu Oct 28 13:08:41 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 28 Oct 2004 15:08:41 +0200 Subject: extfs/iso9660.in In-Reply-To: <4180ED6D.8070102@gmx.de> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> <1098962032.4813.9.camel@athlon.localdomain> <4180ED6D.8070102@gmx.de> Message-ID: <4180EF59.2070101@gmx.de> Roland Illig wrote: > Leonard den Ottolander wrote: > >> Hi, >> >> I wrote: >> >>> - irx = "^. *[0-9]+. "; >>> + irx = "^\[ *[0-9]+[ ]+[0-9]+\] "; >> >> >> >> Brackets around the space in the middle are unnecessary. Use >> >> + irx = "^\[ *[0-9]+ +[0-9]+\] "; >> >> instead. > > > Please read the awk manual ("info gawk") before committing untested code > which does not work. > > > - irx = "^\[ *[0-9]+ +[0-9]+\] "; > > + irx = "^\\[ *[0-9]+ +[0-9]+\\] "; > > Roland > _______________________________________________ > Mc-devel mailing list > http://mail.gnome.org/mailman/listinfo/mc-devel > > From leonard at den.ottolander.nl Thu Oct 28 13:09:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 15:09:25 +0200 Subject: extfs/iso9660.in In-Reply-To: <4180ED6D.8070102@gmx.de> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> <1098962032.4813.9.camel@athlon.localdomain> <4180ED6D.8070102@gmx.de> Message-ID: <1098968965.4813.27.camel@athlon.localdomain> On Thu, 2004-10-28 at 15:00, Roland Illig wrote: > Please read the awk manual ("info gawk") before committing untested code > which does not work. > > > - irx = "^\[ *[0-9]+ +[0-9]+\] "; > > + irx = "^\\[ *[0-9]+ +[0-9]+\\] "; The problem was that the output of isoinfo -l on FreeBSD is different than on Linux. The committed code has thus changed into: + irx = "^\\[ *[0-9]* +[0-9]+\\] "; which works according to Pavel Shirshov. Hope you didn't revert it yet. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Thu Oct 28 13:12:56 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 28 Oct 2004 15:12:56 +0200 Subject: extfs/iso9660.in In-Reply-To: <4180ED6D.8070102@gmx.de> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> <1098962032.4813.9.camel@athlon.localdomain> <4180ED6D.8070102@gmx.de> Message-ID: <4180F058.7010709@gmx.de> Roland Illig wrote: > Please read the awk manual ("info gawk") before committing untested code > which does not work. Sorry, that should have not gone to you (Leonard), as you didn't commit (obviously). ;) Roland From leonard at den.ottolander.nl Thu Oct 28 13:13:39 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 15:13:39 +0200 Subject: extfs/iso9660.in In-Reply-To: <1098968965.4813.27.camel@athlon.localdomain> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> <1098962032.4813.9.camel@athlon.localdomain> <4180ED6D.8070102@gmx.de> <1098968965.4813.27.camel@athlon.localdomain> Message-ID: <1098969218.4813.30.camel@athlon.localdomain> Hello Roland, > > > - irx = "^\[ *[0-9]+ +[0-9]+\] "; > > > + irx = "^\\[ *[0-9]+ +[0-9]+\\] "; > > The problem was that the output of isoinfo -l on FreeBSD is different > than on Linux. The committed code has thus changed into: > > + irx = "^\\[ *[0-9]* +[0-9]+\\] "; Sorry. Committed code is + irx = "^\[ *[0-9]* +[0-9]+\] "; Why do you want to introduce an extra backslash? It's the bracket I want to escape. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Thu Oct 28 13:27:29 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 28 Oct 2004 15:27:29 +0200 Subject: extfs/iso9660.in In-Reply-To: <1098969218.4813.30.camel@athlon.localdomain> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> <1098962032.4813.9.camel@athlon.localdomain> <4180ED6D.8070102@gmx.de> <1098968965.4813.27.camel@athlon.localdomain> <1098969218.4813.30.camel@athlon.localdomain> Message-ID: <4180F3C1.7090506@gmx.de> Leonard den Ottolander wrote: > Hello Roland, > > >>> > - irx = "^\[ *[0-9]+ +[0-9]+\] "; >>> > + irx = "^\\[ *[0-9]+ +[0-9]+\\] "; >> >>The problem was that the output of isoinfo -l on FreeBSD is different >>than on Linux. The committed code has thus changed into: >> >>+ irx = "^\\[ *[0-9]* +[0-9]+\\] "; > > > Sorry. Committed code is > > + irx = "^\[ *[0-9]* +[0-9]+\] "; > > Why do you want to introduce an extra backslash? It's the bracket I want > to escape. The question is: Escape from what? The first interpretation of the string is done by awk, parsing the string literal. This converts the string "\[" into the string "[". The second interpretation is done by the regex compiler which sees a single "[", not a "\[" as intended. Therefore the "\\[" is necessary. Roland From leonard at den.ottolander.nl Thu Oct 28 13:35:35 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 15:35:35 +0200 Subject: extfs/iso9660.in In-Reply-To: <1098969218.4813.30.camel@athlon.localdomain> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> <1098962032.4813.9.camel@athlon.localdomain> <4180ED6D.8070102@gmx.de> <1098968965.4813.27.camel@athlon.localdomain> <1098969218.4813.30.camel@athlon.localdomain> Message-ID: <1098970534.4813.39.camel@athlon.localdomain> Hi, And once more: > Sorry. Committed code is > > + irx = "^\[ *[0-9]* +[0-9]+\] "; You might want to change that into + irx = "^\[ *[0-9]* *[0-9]+\] "; It might be there is not always a space in the expression for large numbers. I think that might be the case for DVDs (media larger than 2GB). Sorry that I didn't think of that before. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Oct 28 13:47:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 15:47:25 +0200 Subject: extfs/iso9660.in In-Reply-To: <4180F3C1.7090506@gmx.de> References: <417FCFFF.6060509@gmx.de> <1098914324.4812.48.camel@athlon.localdomain> <1098962032.4813.9.camel@athlon.localdomain> <4180ED6D.8070102@gmx.de> <1098968965.4813.27.camel@athlon.localdomain> <1098969218.4813.30.camel@athlon.localdomain> <4180F3C1.7090506@gmx.de> Message-ID: <1098971244.4813.52.camel@athlon.localdomain> Hi Roland, On Thu, 2004-10-28 at 15:27, Roland Illig wrote: > The first interpretation of the string is done by awk, parsing the > string literal. This converts the string "\[" into the string "[". The > second interpretation is done by the regex compiler which sees a single > "[", not a "\[" as intended. Therefore the "\\[" is necessary. You might be right. Please correct if you like. (Don't forget to replace ' +' with ' *'.) However, zero, one, two or three backslashes all seem to work. Could it be the placing of the brackets makes that they aren't interpreted anyway? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Oct 28 16:48:09 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 18:48:09 +0200 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: References: Message-ID: <1098982089.4813.10.camel@athlon.localdomain> 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. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nerijus at users.sourceforge.net Thu Oct 28 20:14:52 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Thu, 28 Oct 2004 23:14:52 +0300 (EEST) Subject: building on AIX In-Reply-To: <417AA819.8070302@gmx.de> References: <20041023143255.0CD41508412@mx.ktv.lt> <417AA819.8070302@gmx.de> Message-ID: <20041028201844.2F4365087FE@mx.ktv.lt> On Sat, 23 Oct 2004 20:51:05 +0200 Roland Illig wrote: > > ftpfs.c: In function `ftpfs_initconn': > > ftpfs.c:889: warning: passing arg 3 of `ngetsockname' from incompatible pointer type > > ftpfs.c:912: warning: passing arg 3 of `ngetsockname' from incompatible pointer type > > ftpfs.c: In function `ftpfs_open_data_connection': > > ftpfs.c:957: warning: passing arg 3 of `naccept' from incompatible pointer type > > Thanks for reporting these. > > The patch is to add an AC_CHECK_TYPE(socklen_t, int) to configure.ac > and then replace the types in all the wrong declarations with socklen_t. OK, now these warnings are gone, but there's a new one: In file included from ftpfs.c:60: /usr/include/sys/socket.h:80: warning: empty declaration /usr/include/sys/socket.h:80 is: typedef __ulong32_t socklen_t; While running configure I saw: checking for socklen_t... no And config.h after running configure has: /* Define to `int' if does not define. */ #define socklen_t int If I comment it out then there are no warnings. Regards, Nerijus From leonard at den.ottolander.nl Thu Oct 28 20:54:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 22:54:40 +0200 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: <1098996880.4813.29.camel@athlon.localdomain> Hello Jindrich, On Wed, 2004-10-27 at 18:20, Jindrich Novy wrote: > I tested it and was unable to find any dialog that still shows a > password in it. Patch seems to work. I can't find any dialog with the password visible. However, I do believe this also means no password is ever saved. Not sure if this is what people want, although it is much safer this way :-) . There is one little issue, which is that in the active vfs list the users home directory is started with a double slash (user at host//home/user), which is not the case in other places. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Oct 28 21:40:06 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 28 Oct 2004 23:40:06 +0200 Subject: Once more tar.c ./files Message-ID: <1098999606.4813.38.camel@athlon.localdomain> 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. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: tar.c.diff Type: text/x-patch Size: 876 bytes Desc: not available URL: From me at pavelsh.pp.ru Fri Oct 29 04:05:15 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Fri, 29 Oct 2004 10:05:15 +0600 Subject: [PATCH] completion_matches(): kill duplicate entries In-Reply-To: References: Message-ID: <476787989.20041029100515@pavelsh.pp.ru> Hello Pavel, Wednesday, October 27, 2004, 1:25:26 PM, you wrote: PT> A one liner that fixes duplicate completion matches if there are more PT> than two matches available. This is not a new bug - it was in 4.6.0 and PT> mayber earlier versions (haven't checked though). PT> To reproduce the bug put the same path in PATH three or more times. Try PT> to complete an executable that you know resides in that path. Committed. Thx! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From ptsekov at gmx.net Fri Oct 29 08:56:36 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 29 Oct 2004 10:56:36 +0200 Subject: Internal editor brokeness with ncurses In-Reply-To: References: Message-ID: 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 jnovy at redhat.com Fri Oct 29 15:27:48 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 29 Oct 2004 17:27:48 +0200 Subject: mc crash fix when '\n' is in the directory name Message-ID: <1099063668.28640.115.camel@localhost.localdomain> Hello, the following "uglydir" patch prevents mc from hang when it displays directory with newline '\n' character in the name. As far as I have tested, mc hangs in this case only in non-UTF-8 mode. The original patch by Karel Zak. I adapted it for the recent mc CVS version and let it correct the name only in non-UTF-8 case, otherwise it replaces UTF-8 characters by '?'. For bug reproduction and testing please see bug #127164. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-uglydir.patch Type: text/x-patch Size: 1506 bytes Desc: not available URL: From leonard at den.ottolander.nl Fri Oct 29 15:38:12 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 29 Oct 2004 17:38:12 +0200 Subject: mc crash fix when '\n' is in the directory name In-Reply-To: <1099063668.28640.115.camel@localhost.localdomain> References: <1099063668.28640.115.camel@localhost.localdomain> Message-ID: <1099064291.4781.43.camel@athlon.localdomain> Hi, On Fri, 2004-10-29 at 17:27, Jindrich Novy wrote: > For bug reproduction and testing please see bug #127164. Which points to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127164 , not to Savannah. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Fri Oct 29 13:46:40 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 29 Oct 2004 15:46:40 +0200 Subject: edit_status () prints bad status line Message-ID: 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 leonard at den.ottolander.nl Fri Oct 29 16:27:30 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 29 Oct 2004 18:27:30 +0200 Subject: edit_status () prints bad status line In-Reply-To: References: Message-ID: <1099067250.4781.47.camel@athlon.localdomain> Hello, On Fri, 2004-10-29 at 15:46, Pavel Tsekov wrote: > You should change the line above to: > > printw ("%-*s ", w - (fname_len + gap + 2), status); If this is correct please commit before 4.6.1. However > 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'. I think this should wait until after the release. Not sure how much of the code you want to fix like this but it might be more than just one file. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Fri Oct 29 17:31:10 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 29 Oct 2004 19:31:10 +0200 (MEST) Subject: edit_status () prints bad status line References: <1099067250.4781.47.camel@athlon.localdomain> Message-ID: <3751.1099071070@www16.gmx.net> > > 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'. > > I think this should wait until after the release. Not sure how much of > the code you want to fix like this but it might be more than just one > file. I am speaking about new code here - changes to edit_status (). These changes were introduced with rev. 1.33. If you look at the code you'll see the constant 'gap' and on the other hand you have the right padding which is represented by 2 . Don't take me wrong - I understand that there are many places in the code that use constructs like this already. -- Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD ++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++ From leonard at den.ottolander.nl Fri Oct 29 17:37:56 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 29 Oct 2004 19:37:56 +0200 Subject: edit_status () prints bad status line In-Reply-To: References: Message-ID: <1099071476.4781.58.camel@athlon.localdomain> Hello Pavel, On Fri, 2004-10-29 at 15:46, Pavel Tsekov wrote: > printw ("%-*s ", w - (fname_len + gap + 2), status); Although I see no drawing errors after applying this patch I wonder where the 2 right pad spaces are printed out, since w - (fname_len + gap + 2) + fname_len + gap = w - 2 Care to explain? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Fri Oct 29 19:49:15 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 29 Oct 2004 21:49:15 +0200 (MEST) Subject: edit_status () prints bad status line References: <1099071476.4781.58.camel@athlon.localdomain> Message-ID: <7565.1099079355@www26.gmx.net> Hello, > On Fri, 2004-10-29 at 15:46, Pavel Tsekov wrote: > > printw ("%-*s ", w - (fname_len + gap + 2), status); > > Although I see no drawing errors after applying this patch I wonder > where the 2 right pad spaces are printed out, since > > w - (fname_len + gap + 2) + fname_len + gap = w - 2 Yes. To see the error you need MC linked against ncurses. 1) mcedit /some/file 2) Ctrl + L 3) Watch the second line `w' is the number of columns, so `w - (fname_len + gap)' is everything except fname and the gap, and then you have two more spaces. 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 '*'. -- NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum superg?nstigen Komplett-Preis! From roland.illig at gmx.de Sun Oct 31 18:41:42 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 31 Oct 2004 19:41:42 +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: <418531E6.4000106@gmx.de> Nerijus Baliunas wrote: > OK, now these warnings are gone, but there's a new one: > In file included from ftpfs.c:60: > /usr/include/sys/socket.h:80: warning: empty declaration > > /usr/include/sys/socket.h:80 is: > typedef __ulong32_t socklen_t; > > While running configure I saw: > checking for socklen_t... no I think I know the reason for it. Please add the sys/socket.h header to the list of headers in line 152..155 and rebuild the configure script. Then everything should work. Roland From roland.illig at gmx.de Sun Oct 31 18:42:32 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 31 Oct 2004 19:42:32 +0100 Subject: building on AIX In-Reply-To: <418531E6.4000106@gmx.de> References: <20041023143255.0CD41508412@mx.ktv.lt> <417AA819.8070302@gmx.de> <20041028201844.2F4365087FE@mx.ktv.lt> <418531E6.4000106@gmx.de> Message-ID: <41853218.200@gmx.de> I wrote: > the list of headers in line 152..155 and rebuild the configure script. line 152..155 of configure.ac Roland From leonard at den.ottolander.nl Sun Oct 31 21:26:38 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 31 Oct 2004 22:26:38 +0100 Subject: Do we need _ISOC99_SOURCE in the utf8-input patch? Message-ID: <1099257998.4814.8.camel@athlon.localdomain> Hi, Is it really necessary to conform to ISO C99? It seems people can't compile mc with gcc-2.95 because of this. Also I see warnings for redefinitions as you don't #ifndef _ISOC99_SOURCE in edit.h. I think it's probably best to drop this from the utf8-input patch altogether. Any compelling reasons why we would need it? Also I get 4 discarded qualifiers: file.c:174: warning: passing arg 1 of `fix_utf8' discards qualifiers from pointer target type file.c:181: warning: passing arg 1 of `g_free' discards qualifiers from pointer target type file.c:225: warning: passing arg 1 of `g_free' discards qualifiers from pointer target type file.c:240: warning: passing arg 1 of `g_free' discards qualifiers from pointer target type Leonard. -- mount -t life -o ro /dev/dna /genetic/research