From jnovy at redhat.com Wed Nov 1 09:23:45 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 01 Nov 2006 10:23:45 +0100 Subject: [PATCH] RPM vfs ignores conflicts In-Reply-To: <1162323847.2869.1.camel@athlon> References: <1162307240.2372.22.camel@redhat.usu> <1162323847.2869.1.camel@athlon> Message-ID: <1162373025.3947.4.camel@redhat.usu> Hi Leonard, On Tue, 2006-10-31 at 20:44 +0100, Leonard den Ottolander wrote: > Hi Jindrich, > > On Tue, 2006-10-31 at 16:07 +0100, Jindrich Novy wrote: > > the current RPM vfs allows to see RPM package requires/provides and > > obsoletes but lacks an implementation of conflicts. The attached patch > > adds INFO/CONFLICTS to the RPM vfs so that conflicts are no more hidden. > > While you're at it, could you provide a similar patch for rpms please? sure :) here we go with the patched trpm vfs as well. rpms fortunately doesn't need any changes. Cheers, Jindrich -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-rpmconf.patch Type: text/x-patch Size: 2773 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Nov 1 10:31:50 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 11:31:50 +0100 Subject: [PATCH] RPM vfs ignores conflicts In-Reply-To: <1162373025.3947.4.camel@redhat.usu> References: <1162307240.2372.22.camel@redhat.usu> <1162323847.2869.1.camel@athlon> <1162373025.3947.4.camel@redhat.usu> Message-ID: <1162377110.2872.1.camel@athlon> Hi Jindrich, On Wed, 2006-11-01 at 10:23 +0100, Jindrich Novy wrote: > sure :) here we go with the patched trpm vfs as well. rpms fortunately > doesn't need any changes. Yes, of course, trpm. Committed. Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 1 10:47:41 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 11:47:41 +0100 Subject: [bug #18042] cannot specify port number in shell link In-Reply-To: <20061030-120454.sv13840.18204@savannah.gnu.org> References: <20061017-125118.sv53419.97238@savannah.gnu.org> <20061027-121503.sv13840.75338@savannah.gnu.org> <20061028-144321.sv26390.16214@savannah.gnu.org> <20061030-120454.sv13840.18204@savannah.gnu.org> Message-ID: <1162378062.2872.9.camel@athlon> Hello Andrew, On Mon, 2006-10-30 at 12:04 +0000, Andrew V. Samoilov wrote: > Follow-up Comment #3, bug #18042 (project mc): > > > Do I understand correctly that a port number *can* be combined with C _or_ > r? > No. Look at utilvfs.c:vfs_split_url(). > No one syntax change. Only undocumented behaviour changed. > It is possible to use /#sh:user at host:6789 right now. Maybe we should introduce a syntax change, because at least the combination of a port number and C are very welcome. What about a solution whereby the user can add any of these options, in any particular order, all separated by colons? Would that be a lot of work to implement? > And fish uses port&1 as 'C' option and port&2 as 'r'. > > Possible solution is to use 0x10000<<1 and 0x10000<<2 instead of 1 and 2. That would probably get rid of the need for an extra parameter to separate the port number from other options. > I am not sure we can allow such redesign because of lack of manpower. Do I understand correctly that you are not willing to implement such a change? Can we at least agree on a new syntax if somebody (I?) would be willing to implement it? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Wed Nov 1 11:20:48 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 1 Nov 2006 13:20:48 +0200 (EET) Subject: [bug #18042] cannot specify port number in shell link In-Reply-To: <1162378062.2872.9.camel@athlon> References: <20061017-125118.sv53419.97238@savannah.gnu.org> <20061027-121503.sv13840.75338@savannah.gnu.org> <20061028-144321.sv26390.16214@savannah.gnu.org> <20061030-120454.sv13840.18204@savannah.gnu.org> <1162378062.2872.9.camel@athlon> Message-ID: On Wed, 1 Nov 2006, Leonard den Ottolander wrote: > Hello Andrew, > > On Mon, 2006-10-30 at 12:04 +0000, Andrew V. Samoilov wrote: >> Follow-up Comment #3, bug #18042 (project mc): >> >>> Do I understand correctly that a port number *can* be combined with C _or_ >> r? > >> No. Look at utilvfs.c:vfs_split_url(). >> No one syntax change. Only undocumented behaviour changed. >> It is possible to use /#sh:user at host:6789 right now. > > Maybe we should introduce a syntax change, because at least the > combination of a port number and C are very welcome. > > What about a solution whereby the user can add any of these options, in > any particular order, all separated by colons? Would that be a lot of > work to implement? > >> And fish uses port&1 as 'C' option and port&2 as 'r'. >> >> Possible solution is to use 0x10000<<1 and 0x10000<<2 instead of 1 and 2. > > That would probably get rid of the need for an extra parameter to > separate the port number from other options. The port clearly belongs to the url, as do the hostname, the username, the password and the location. Options are hardly candidates to become part of the url. IMO, it would be better if MC pops up an url specific dialog for each vfs if necessary so that the user could finer tune the connection. I think this would also help to add support for per connection settings i.e. use passive ftp for one connection and active for another. Instead of simple hacks we'd better go with well designed features. From ptsekov at gmx.net Wed Nov 1 11:27:43 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 1 Nov 2006 13:27:43 +0200 (EET) Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <1162324011.2869.5.camel@athlon> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> Message-ID: On Tue, 31 Oct 2006, Leonard den Ottolander wrote: > On Mon, 2006-10-30 at 11:45 +0200, Pavel Tsekov wrote: >> IMO, if you intend to work on a fix you should follow the >> suggestion of the bash maintainer to switch over to using >> "printf" - not only for bash but for all cases. Of course >> a fallback may be required. After all according to bash >> maintainer: >> >> "Use of `echo' in portable applications has been deprecated for years." >> >> See: http://www.mail-archive.com/bug-bash at gnu.org/msg02150.html > > Yes, I read that comment. However I'm not prepared to start breaking the > functionality of shells that I never use. This is a rather strange statement. As a developer you should try to go beyond your personal preferences. Changes to the subshell shall be tested with all supported shells and on as many platforms as possible. >From Chet Ramey's statement it is clear that using printf is the right thing to do. From dickey at his.com Wed Nov 1 11:55:16 2006 From: dickey at his.com (Thomas Dickey) Date: Wed, 1 Nov 2006 06:55:16 -0500 (EST) Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> Message-ID: <20061101065337.T12697@mail101.his.com> On Wed, 1 Nov 2006, Pavel Tsekov wrote: >> Yes, I read that comment. However I'm not prepared to start breaking the >> functionality of shells that I never use. > > This is a rather strange statement. As a developer you should try to > go beyond your personal preferences. Changes to the subshell shall be > tested with all supported shells and on as many platforms as possible. >> From Chet Ramey's statement it is clear that using printf is the right > thing to do. That's his statement. Jim Meyering's comment is more reasonable. (bash 3.2 is broken anyway - perhaps 3.3 will be usable). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net From ptsekov at gmx.net Wed Nov 1 12:04:34 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 1 Nov 2006 14:04:34 +0200 (EET) Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061101065337.T12697@mail101.his.com> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> Message-ID: On Wed, 1 Nov 2006, Thomas Dickey wrote: > On Wed, 1 Nov 2006, Pavel Tsekov wrote: > >>> Yes, I read that comment. However I'm not prepared to start breaking the >>> functionality of shells that I never use. >> >> This is a rather strange statement. As a developer you should try to >> go beyond your personal preferences. Changes to the subshell shall be >> tested with all supported shells and on as many platforms as possible. >>> From Chet Ramey's statement it is clear that using printf is the right >> thing to do. > > That's his statement. Jim Meyering's comment is more reasonable. His comment is related to coreutils and not bash. Anyway, he still agrees that "printf" should be used. If this is the way to go why shall we wait ? From dickey at his.com Wed Nov 1 12:14:09 2006 From: dickey at his.com (Thomas Dickey) Date: Wed, 1 Nov 2006 07:14:09 -0500 (EST) Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> Message-ID: <20061101071107.O18826@mail101.his.com> On Wed, 1 Nov 2006, Pavel Tsekov wrote: > On Wed, 1 Nov 2006, Thomas Dickey wrote: > >> On Wed, 1 Nov 2006, Pavel Tsekov wrote: >> >>>> Yes, I read that comment. However I'm not prepared to start breaking the >>>> functionality of shells that I never use. >>> >>> This is a rather strange statement. As a developer you should try to >>> go beyond your personal preferences. Changes to the subshell shall be >>> tested with all supported shells and on as many platforms as possible. >>>> From Chet Ramey's statement it is clear that using printf is the right >>> thing to do. >> >> That's his statement. Jim Meyering's comment is more reasonable. > > His comment is related to coreutils and not bash. Anyway, he still > agrees that "printf" should be used. If this is the way to go why > shall we wait ? He's recommending it for new scripts, not recommending that one rewrite existing scripts (and by noting that other shells retain the existing treatment, is pointing out a problem). Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in existing scripts to bother with 3.2.x). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net From ptsekov at gmx.net Wed Nov 1 12:30:25 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 1 Nov 2006 14:30:25 +0200 (EET) Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061101071107.O18826@mail101.his.com> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> <20061101071107.O18826@mail101.his.com> Message-ID: On Wed, 1 Nov 2006, Thomas Dickey wrote: > On Wed, 1 Nov 2006, Pavel Tsekov wrote: > >> On Wed, 1 Nov 2006, Thomas Dickey wrote: >> >>> On Wed, 1 Nov 2006, Pavel Tsekov wrote: >>> >>>>> Yes, I read that comment. However I'm not prepared to start breaking the >>>>> functionality of shells that I never use. >>>> >>>> This is a rather strange statement. As a developer you should try to >>>> go beyond your personal preferences. Changes to the subshell shall be >>>> tested with all supported shells and on as many platforms as possible. >>>>> From Chet Ramey's statement it is clear that using printf is the right >>>> thing to do. >>> >>> That's his statement. Jim Meyering's comment is more reasonable. >> >> His comment is related to coreutils and not bash. Anyway, he still >> agrees that "printf" should be used. If this is the way to go why >> shall we wait ? > > He's recommending it for new scripts, not recommending that one rewrite > existing scripts (and by noting that other shells retain the existing > treatment, is pointing out a problem). Ok. Since I am not native english speaker I cannot judge whether he is recommending it or not. In any case I can see why keeping the old behaviour of 'echo' is important for large scripts, however what we have in MC is nothing as big. I just feel that what Leonard is proposing is a hack and not an actual solution. > Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in > existing scripts to bother with 3.2.x). Does this mean that you think that bash 3.3 will reinstantiate the old behaviour ? From dickey at his.com Wed Nov 1 12:51:08 2006 From: dickey at his.com (Thomas Dickey) Date: Wed, 1 Nov 2006 07:51:08 -0500 (EST) Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> <20061101071107.O18826@mail101.his.com> Message-ID: <20061101074531.A29639@mail101.his.com> On Wed, 1 Nov 2006, Pavel Tsekov wrote: > Ok. Since I am not native english speaker I cannot judge whether > he is recommending it or not. In any case I can see why keeping > the old behaviour of 'echo' is important for large scripts, however > what we have in MC is nothing as big. I just feel that what Leonard > is proposing is a hack and not an actual solution. > >> Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in >> existing scripts to bother with 3.2.x). > > Does this mean that you think that bash 3.3 will reinstantiate the old > behaviour ? Not for this ("echo -e" is a dead issue, though some of the discussion there touches on other problems). But it would be reasonable to expect it to fix the syntax errors. Before rushing off to change things to accommodate bash 3.2, it's worth checking if the fix will work with other shells. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net From leonard at den.ottolander.nl Wed Nov 1 12:54:28 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 13:54:28 +0100 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> Message-ID: <1162385668.2872.18.camel@athlon> Hello Pavel, On Wed, 2006-11-01 at 13:27 +0200, Pavel Tsekov wrote: > > Yes, I read that comment. However I'm not prepared to start breaking the > > functionality of shells that I never use. > > This is a rather strange statement. As a developer you should try to > go beyond your personal preferences. As I have limited time I will not be implementing a solution where we replace echo -e with printf. It's not that I don't prefer such a solution, it's just that I will not be implementing it as it will take me too much time. As we are faced with an acute breaking when using bash >= 3.2 I am prepared to create a patch that fixes the octal issue. Please let me know if you will be fixing the issue properly by replacing echo -e with printf. If not I will create a fix for the octals issue as the breakage of bash > 3.2 needs to be fixed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Wed Nov 1 12:55:49 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 1 Nov 2006 14:55:49 +0200 (EET) Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061101074531.A29639@mail101.his.com> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> <20061101071107.O18826@mail101.his.com> <20061101074531.A29639@mail101.his.com> Message-ID: On Wed, 1 Nov 2006, Thomas Dickey wrote: > On Wed, 1 Nov 2006, Pavel Tsekov wrote: > >> Ok. Since I am not native english speaker I cannot judge whether >> he is recommending it or not. In any case I can see why keeping >> the old behaviour of 'echo' is important for large scripts, however >> what we have in MC is nothing as big. I just feel that what Leonard >> is proposing is a hack and not an actual solution. >> >>> Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in >>> existing scripts to bother with 3.2.x). >> >> Does this mean that you think that bash 3.3 will reinstantiate the old >> behaviour ? > > Not for this ("echo -e" is a dead issue, though some of the discussion there > touches on other problems). But it would be reasonable to expect it to fix > the syntax errors. Before rushing off to change things to accommodate bash > 3.2, it's worth checking if the fix will work with other shells. The fix which Leonard proposes would not affect the other supported shells. Look at subshell_name_quote() in subshell.c. I am beginning to wonther whether do we really want to escape the characters using "echo" or "printf". From leonard at den.ottolander.nl Wed Nov 1 13:07:19 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 14:07:19 +0100 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> <20061101071107.O18826@mail101.his.com> <20061101074531.A29639@mail101.his.com> Message-ID: <1162386439.2872.28.camel@athlon> On Wed, 2006-11-01 at 14:55 +0200, Pavel Tsekov wrote: > I am beginning > to wonther whether do we really want to escape the characters > using "echo" or "printf". For embedded backslashes etc. I suppose we do. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 1 13:10:40 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 14:10:40 +0100 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061101074531.A29639@mail101.his.com> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> <20061101071107.O18826@mail101.his.com> <20061101074531.A29639@mail101.his.com> Message-ID: <1162386640.2872.32.camel@athlon> Hello Thomas, On Wed, 2006-11-01 at 07:51 -0500, Thomas Dickey wrote: > Before rushing off to change things to > accommodate bash 3.2, it's worth checking if the fix will work with other > shells. I'm not quite sure which fix you are referring to here. The temporary hack I send to this list should not break the other shells. All it does is add quoting of numbers for these shells. For the (temporary, echo -e) fix I had in mind even this change would be dropped. My idea was to add an ini option bash_oct_digits with possible values 0 (or unset) (automatically detect version via BASH_VERSION in the calling environment (actually querying the subshell seems a bit much) or fallback), 1 ("compatibility mode", 4 digit octals with numbers quoted, for bash >= 2.05b), 3 ("legacy mode", only use 3 digit octals, no need to escape digits) and 4 (use 4 digit octals only, no need to escape digits, for bash >= 3.2). Please let me know if there are volunteers to implement the proper solution (using printf) so I don't have to waste my time on a patch that is unnecessary. Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 1 13:15:34 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 14:15:34 +0100 Subject: [bug #18042] cannot specify port number in shell link In-Reply-To: References: <20061017-125118.sv53419.97238@savannah.gnu.org> <20061027-121503.sv13840.75338@savannah.gnu.org> <20061028-144321.sv26390.16214@savannah.gnu.org> <20061030-120454.sv13840.18204@savannah.gnu.org> <1162378062.2872.9.camel@athlon> Message-ID: <1162386934.2872.38.camel@athlon> Hello Pavel, On Wed, 2006-11-01 at 13:20 +0200, Pavel Tsekov wrote: > IMO, it would be better if MC pops up an url specific dialog for > each vfs if necessary so that the user could finer tune the connection. I > think this would also help to add support for per connection settings i.e. > use passive ftp for one connection and active for another. Instead of > simple hacks we'd better go with well designed features. Agreed. But as Andrew also pointed out manpower is limited, so sadly we will sometimes have to use hacks if nobody is volunteering to invest time in the proper solution. They are not optimal, but in some cases better than not fixing breakage at all. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Wed Nov 1 13:15:52 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 1 Nov 2006 15:15:52 +0200 (EET) Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <1162386640.2872.32.camel@athlon> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> <20061101071107.O18826@mail101.his.com> <20061101074531.A29639@mail101.his.com> <1162386640.2872.32.camel@athlon> Message-ID: On Wed, 1 Nov 2006, Leonard den Ottolander wrote: > On Wed, 2006-11-01 at 07:51 -0500, Thomas Dickey wrote: >> Before rushing off to change things to >> accommodate bash 3.2, it's worth checking if the fix will work with other >> shells. > > I'm not quite sure which fix you are referring to here. The temporary > hack I send to this list should not break the other shells. All it does > is add quoting of numbers for these shells. For the (temporary, echo -e) > fix I had in mind even this change would be dropped. > > My idea was to add an ini option bash_oct_digits with possible values 0 > (or unset) (automatically detect version via BASH_VERSION in the calling > environment (actually querying the subshell seems a bit much) or > fallback), 1 ("compatibility mode", 4 digit octals with numbers quoted, > for bash >= 2.05b), 3 ("legacy mode", only use 3 digit octals, no need > to escape digits) and 4 (use 4 digit octals only, no need to escape > digits, for bash >= 3.2). That is too much. Please, don't do this. > Please let me know if there are volunteers to implement the proper > solution (using printf) so I don't have to waste my time on a patch that > is unnecessary. Thanks. The "printf" solution wouldn't be that hard to implement in fact. It may be even simpler. I can look at it. From leonard at den.ottolander.nl Wed Nov 1 13:19:32 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 14:19:32 +0100 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> <20061101071107.O18826@mail101.his.com> <20061101074531.A29639@mail101.his.com> <1162386640.2872.32.camel@athlon> Message-ID: <1162387172.2872.40.camel@athlon> On Wed, 2006-11-01 at 15:15 +0200, Pavel Tsekov wrote: > The "printf" solution wouldn't be that hard to implement in fact. It > may be even simpler. I can look at it. That would be nice. Thank you. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Wed Nov 1 13:26:22 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 1 Nov 2006 15:26:22 +0200 (EET) Subject: [bug #18042] cannot specify port number in shell link In-Reply-To: <1162386934.2872.38.camel@athlon> References: <20061017-125118.sv53419.97238@savannah.gnu.org> <20061027-121503.sv13840.75338@savannah.gnu.org> <20061028-144321.sv26390.16214@savannah.gnu.org> <20061030-120454.sv13840.18204@savannah.gnu.org> <1162378062.2872.9.camel@athlon> <1162386934.2872.38.camel@athlon> Message-ID: On Wed, 1 Nov 2006, Leonard den Ottolander wrote: > On Wed, 2006-11-01 at 13:20 +0200, Pavel Tsekov wrote: >> IMO, it would be better if MC pops up an url specific dialog for >> each vfs if necessary so that the user could finer tune the connection. I >> think this would also help to add support for per connection settings i.e. >> use passive ftp for one connection and active for another. Instead of >> simple hacks we'd better go with well designed features. > > Agreed. > > But as Andrew also pointed out manpower is limited, so sadly we will > sometimes have to use hacks if nobody is volunteering to invest time in > the proper solution. They are not optimal, but in some cases better than > not fixing breakage at all. This is not a task which requires tremendous efforts. It is just a matter of defining what we want to do and how we want to do it. And in the meantime there is an easy workaround - just set the port in ~/.ssh/config. From leonard at den.ottolander.nl Wed Nov 1 13:36:58 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 14:36:58 +0100 Subject: [bug #18042] cannot specify port number in shell link In-Reply-To: References: <20061017-125118.sv53419.97238@savannah.gnu.org> <20061027-121503.sv13840.75338@savannah.gnu.org> <20061028-144321.sv26390.16214@savannah.gnu.org> <20061030-120454.sv13840.18204@savannah.gnu.org> <1162378062.2872.9.camel@athlon> <1162386934.2872.38.camel@athlon> Message-ID: <1162388218.2872.43.camel@athlon> Hello Pavel, On Wed, 2006-11-01 at 15:26 +0200, Pavel Tsekov wrote: > This is not a task which requires tremendous efforts. It is just a matter > of defining what we want to do and how we want to do it. And in the > meantime there is an easy workaround - just set the port in ~/.ssh/config. Yes, with the "we sometimes need hacks" I was not referring to this issue. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 1 13:58:41 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 01 Nov 2006 14:58:41 +0100 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061101083215.E44883@mail101.his.com> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <1162041117.2875.6.camel@athlon> <1162042249.2875.15.camel@athlon> <1162043071.2875.24.camel@athlon> <1162072109.2586.7.camel@frugal64> <1162130470.2953.7.camel@athlon> <1162324011.2869.5.camel@athlon> <20061101065337.T12697@mail101.his.com> <20061101071107.O18826@mail101.his.com> <20061101074531.A29639@mail101.his.com> <1162386640.2872.32.camel@athlon> <20061101083215.E44883@mail101.his.com> Message-ID: <1162389522.2872.49.camel@athlon> Hello Thomas, On Wed, 2006-11-01 at 08:38 -0500, Thomas Dickey wrote: > One problem is that the user has to keep track (for the non-automatic > workarounds) of the bash version. No. Default setting of 0 (or unset) of bash_octal_digits would fallback to option 1, which works for bash >= 2.05b (in contrast to the current situation where by default only bash < 3.2 will work). Only users of bash < 2.05b will have to either export BASH_VERSION (iiuc BASH_VERSINFO is a set variable, not an environment var so unusable unless one directly queries the subshell) or set bash_octal_digits to 3. > Pavel's the person to talk to (I maintain other programs including > ncurses) - my point here was noting that bash 3.2 added other problems > which are definitely _bugs_ in bash, and that it would not be good to cite > "3.2" itself as a good example, but to focus on the feature. The issue of the octal length is independent of any bugs in bash 3.2 and will also exist for later versions. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nerijus at users.sourceforge.net Wed Nov 1 22:57:11 2006 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Thu, 2 Nov 2006 00:57:11 +0200 Subject: find in viewer In-Reply-To: References: <20060327212935.F3B7FBAD0@mx.dtiltas.lt> <20060518171757.GC19615@ugly.local> Message-ID: <20061101230159.9C14DFF0A@mx-a.vdnet.lt> Hello, could this patch please be committed to cvs (I am attaching it for your convenience)? BTW, how this patch works when two mc are running? If I search in 1st mc, then in 2nd mc, and then again in 1st mc, what will I get - last text from 1st or 2nd? I'd prefer from 1st, i.e. different mc sessions to be independent. Regards, Nerijus On Tue, 23 May 2006 15:44:30 +0300 (EEST) Pavel Tsekov wrote: > > On Thu, May 18, 2006 at 05:42:45PM +0300, Pavel Tsekov wrote: > >> I guess in the long term the last seach string should be remembered > >> onto persistent storage as for example the file positions. > >> > > yes. > > How about the following patch ? This is not a final version - I am just > posting it to see whether you like the idea. The patch uses the input > field's ability to automatically retrieve the last entered text from > the history. The last search expression would be loaded in the input > field even after you've exited MC and then launch it again - this differs > from the old behaviour where the search expression would be lost on MC > exit. -------------- next part -------------- A non-text attachment was scrubbed... Name: view-persistent-search.patch Type: application/octet-stream Size: 1769 bytes Desc: not available URL: From ptsekov at gmx.net Thu Nov 2 07:51:58 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 2 Nov 2006 09:51:58 +0200 (EET) Subject: find in viewer In-Reply-To: <20061101230159.9C14DFF0A@mx-a.vdnet.lt> References: <20060327212935.F3B7FBAD0@mx.dtiltas.lt> <20060518171757.GC19615@ugly.local> <20061101230159.9C14DFF0A@mx-a.vdnet.lt> Message-ID: On Thu, 2 Nov 2006, Nerijus Baliunas wrote: > Hello, > > could this patch please be committed to cvs (I am attaching it for your convenience)? > BTW, how this patch works when two mc are running? If I search in 1st mc, > then in 2nd mc, and then again in 1st mc, what will I get - last text from > 1st or 2nd? I'd prefer from 1st, i.e. different mc sessions to be independent. This patch is not as good. Something else should be used. Reverting the original code that broke this feature might be better option for now. I'll try to do something about it till the weekend. From INVALID.NOREPLY at gnu.org Fri Nov 3 05:21:05 2006 From: INVALID.NOREPLY at gnu.org (Andrey) Date: Fri, 03 Nov 2006 05:21:05 +0000 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061028-122212.sv20252.99093@savannah.gnu.org> References: <20061028-122212.sv20252.99093@savannah.gnu.org> Message-ID: <20061103-052104.sv53977.52633@savannah.gnu.org> Follow-up Comment #1, bug #18136 (project mc): I made the patch to work with bash 3.2. Apparently bash changed to the way of handling character codes similar to that of tsch. I have not tested it well and not checked it with bash 3.1. Report any problems here. _______________________________________________________ Additional Item Attachment: File name: mc-4.6.1-bash-3.2.patch Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 3 17:23:30 2006 From: INVALID.NOREPLY at gnu.org (Matt) Date: Fri, 03 Nov 2006 17:23:30 +0000 Subject: [bug #18191] mc crashes with segmentation violation when viewing /proc/registers Message-ID: <20061103-172330.sv54001.25671@savannah.gnu.org> URL: Summary: mc crashes with segmentation violation when viewing /proc/registers Project: GNU Midnight Commander Submitted by: mjm Submitted on: Friday 11/03/2006 at 17:23 Category: Viewer Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Open/Closed: Open Release: 4.6.1 Operating System: GNU/Linux _______________________________________________________ Details: I found a bug which causes mc to crash with segmentation violation when trying view any of the /proc/registers files. This was only tested on gentoo-2006.1. I have no knowledge whether this crashes the program on other distributions or operating systems. I am currenlty working on an exploit for this bug in my free time. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 3 19:14:56 2006 From: INVALID.NOREPLY at gnu.org (Leonard den Ottolander) Date: Fri, 03 Nov 2006 19:14:56 +0000 Subject: [bug #17822] consecutive resize events not handled correctly In-Reply-To: <20061010-162216.sv20032.56238@savannah.gnu.org> References: <20060922-130444.sv20032.6027@savannah.gnu.org> <20061010-152747.sv20032.29475@savannah.gnu.org> <20061010-154051.sv20032.92680@savannah.gnu.org> <20061010-162058.sv20032.59845@savannah.gnu.org> <20061010-162216.sv20032.56238@savannah.gnu.org> Message-ID: <20061103-201455.sv26390.25558@savannah.gnu.org> Follow-up Comment #4, bug #17822 (project mc): Shall I commit this patch or should I wait for the piped version? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 3 21:32:57 2006 From: INVALID.NOREPLY at gnu.org (Roland Illig) Date: Fri, 03 Nov 2006 21:32:57 +0000 Subject: [bug #18191] mc crashes with segmentation violation when viewing /proc/registers In-Reply-To: <20061103-172330.sv54001.25671@savannah.gnu.org> References: <20061103-172330.sv54001.25671@savannah.gnu.org> Message-ID: <20061103-223257.sv20990.23594@savannah.gnu.org> Follow-up Comment #1, bug #18191 (project mc): Note: this is fixed in the CVS version of mc, in which the viewer has been rewritten in large parts. _______________________________________________________ Reply to this item at: _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 6 12:01:58 2006 From: INVALID.NOREPLY at gnu.org (Egmont Koblinger) Date: Mon, 06 Nov 2006 12:01:58 +0000 Subject: [bug #17822] consecutive resize events not handled correctly In-Reply-To: <20061103-201455.sv26390.25558@savannah.gnu.org> References: <20060922-130444.sv20032.6027@savannah.gnu.org> <20061010-152747.sv20032.29475@savannah.gnu.org> <20061010-154051.sv20032.92680@savannah.gnu.org> <20061010-162058.sv20032.59845@savannah.gnu.org> <20061010-162216.sv20032.56238@savannah.gnu.org> <20061103-201455.sv26390.25558@savannah.gnu.org> Message-ID: <20061106-120158.sv20032.81600@savannah.gnu.org> Follow-up Comment #5, bug #17822 (project mc): Please commit it if it seems to be okay for you (I've been using mc 4.6.1 with this patch for a month, and found no side effects, while it makes mc much better when resizing the terminal). But please don't yet close this bugreport to remind us that a proper fix is still needed. This patch only makes it much better, but still there's a small chance for the bug to appear. Until we have a proper fix, it's good to apply a temporary hack to heavily decrease the chance for the bug. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 6 22:24:35 2006 From: INVALID.NOREPLY at gnu.org (Leonard den Ottolander) Date: Mon, 06 Nov 2006 22:24:35 +0000 Subject: [bug #17822] consecutive resize events not handled correctly In-Reply-To: <20061106-120158.sv20032.81600@savannah.gnu.org> References: <20060922-130444.sv20032.6027@savannah.gnu.org> <20061010-152747.sv20032.29475@savannah.gnu.org> <20061010-154051.sv20032.92680@savannah.gnu.org> <20061010-162058.sv20032.59845@savannah.gnu.org> <20061010-162216.sv20032.56238@savannah.gnu.org> <20061103-201455.sv26390.25558@savannah.gnu.org> <20061106-120158.sv20032.81600@savannah.gnu.org> Message-ID: <20061106-232435.sv26390.80397@savannah.gnu.org> Follow-up Comment #6, bug #17822 (project mc): As I understand your patch/hack, eliminating the timeouts on a window resize event significantly reduces the chance mc is still waiting inside the get_event() loop when a new resize event occurs. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 8 13:38:24 2006 From: INVALID.NOREPLY at gnu.org (Leonard den Ottolander) Date: Wed, 08 Nov 2006 13:38:24 +0000 Subject: [bug #17822] consecutive resize events not handled correctly In-Reply-To: <20061106-232435.sv26390.80397@savannah.gnu.org> References: <20060922-130444.sv20032.6027@savannah.gnu.org> <20061010-152747.sv20032.29475@savannah.gnu.org> <20061010-154051.sv20032.92680@savannah.gnu.org> <20061010-162058.sv20032.59845@savannah.gnu.org> <20061010-162216.sv20032.56238@savannah.gnu.org> <20061103-201455.sv26390.25558@savannah.gnu.org> <20061106-120158.sv20032.81600@savannah.gnu.org> <20061106-232435.sv26390.80397@savannah.gnu.org> Message-ID: <20061108-143824.sv26390.52630@savannah.gnu.org> Follow-up Comment #7, bug #17822 (project mc): Committed. Quite an improvement in behaviour. Thank you. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From jnovy at redhat.com Wed Nov 8 18:37:47 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 08 Nov 2006 19:37:47 +0100 Subject: [PATCH] FISH DoS when copying file with '`' in name to remote FS Message-ID: <1163011067.2514.25.camel@redhat.usu> Hi all, there's a problem when copying file named like "file`" to remote filesystem via FISH. It simply won't do anything because of error in BASH script which is generated in vfs/fish.c caused by the filename. Attached patch should fix it. References: http://bugzilla.redhat.com/214255 Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-fishfix.patch Type: text/x-patch Size: 1627 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Nov 8 22:05:17 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 08 Nov 2006 23:05:17 +0100 Subject: [PATCH] FISH DoS when copying file with '`' in name to remote FS In-Reply-To: <1163011067.2514.25.camel@redhat.usu> References: <1163011067.2514.25.camel@redhat.usu> Message-ID: <1163023518.2833.19.camel@athlon> Hi Jindrich, On Wed, 2006-11-08 at 19:37 +0100, Jindrich Novy wrote: > + "file=/%s\n" Why the substitution instead of just quoting the occurrences of %s? > (unsigned long) s.st_size, name, > - (unsigned long) s.st_size, quoted_name, > - quoted_name, (unsigned long) s.st_size, quoted_name); > + quoted_name, (unsigned long) s.st_size, > + (unsigned long) s.st_size); And what is this doing? Is it in any way related to the quoting issue or does it fix something else? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jnovy at redhat.com Thu Nov 9 12:44:47 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 09 Nov 2006 13:44:47 +0100 Subject: [PATCH] FISH DoS when copying file with '`' in name to remote FS In-Reply-To: <1163023518.2833.19.camel@athlon> References: <1163011067.2514.25.camel@redhat.usu> <1163023518.2833.19.camel@athlon> Message-ID: <1163076287.2363.58.camel@redhat.usu> Hi Leonard, On Wed, 2006-11-08 at 23:05 +0100, Leonard den Ottolander wrote: > Hi Jindrich, > > On Wed, 2006-11-08 at 19:37 +0100, Jindrich Novy wrote: > > + "file=/%s\n" > > Why the substitution instead of just quoting the occurrences of %s? I was fixing this bug by generating the scripts to log and then trying to quote them appropriately to make them work. I was unsuccessful to fix the script responsible for this bug by any quotation as backtick '`' did quite bad things so that bash was unable to parse it, quoted or not. Maybe I'm at fault here, but the problem cannot be fixed by quoting only. > > (unsigned long) s.st_size, name, > > - (unsigned long) s.st_size, quoted_name, > > - quoted_name, (unsigned long) s.st_size, quoted_name); > > + quoted_name, (unsigned long) s.st_size, > > + (unsigned long) s.st_size); > > And what is this doing? Is it in any way related to the quoting issue or > does it fix something else? This is because fish_command() has variable arguments. So I removed the arguments referenced by %s in the format string as I replaced some of them by $file reference. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V From leonard at den.ottolander.nl Thu Nov 9 18:00:45 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 09 Nov 2006 19:00:45 +0100 Subject: [PATCH] FISH DoS when copying file with '`' in name to remote FS In-Reply-To: <1163076287.2363.58.camel@redhat.usu> References: <1163011067.2514.25.camel@redhat.usu> <1163023518.2833.19.camel@athlon> <1163076287.2363.58.camel@redhat.usu> Message-ID: <1163095246.2965.1.camel@athlon> Hi Jindrich, On Thu, 2006-11-09 at 13:44 +0100, Jindrich Novy wrote: > I was unsuccessful to fix > the script responsible for this bug by any quotation as backtick '`' did > quite bad things so that bash was unable to parse it, quoted or not. Thanks for your explanation. Committed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From INVALID.NOREPLY at gnu.org Sun Nov 12 14:18:32 2006 From: INVALID.NOREPLY at gnu.org (Mehmet Kemal EROL) Date: Sun, 12 Nov 2006 14:18:32 +0000 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061103-052104.sv53977.52633@savannah.gnu.org> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <20061103-052104.sv53977.52633@savannah.gnu.org> Message-ID: <20061112-161831.sv54310.97804@savannah.gnu.org> Follow-up Comment #2, bug #18136 (project mc): Thank you very much, dear Andrey! I have made an ebuild for Gentoo containing your patch, which solved the reported problems. Please see here: http://bugs.gentoo.org/show_bug.cgi?id=153925 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Nov 12 16:54:27 2006 From: INVALID.NOREPLY at gnu.org (Leonard den Ottolander) Date: Sun, 12 Nov 2006 16:54:27 +0000 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061112-161831.sv54310.97804@savannah.gnu.org> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <20061103-052104.sv53977.52633@savannah.gnu.org> <20061112-161831.sv54310.97804@savannah.gnu.org> Message-ID: <20061112-175426.sv26390.46745@savannah.gnu.org> Follow-up Comment #3, bug #18136 (project mc): Mehmet, instead of using the attached patch that breaks compatibility with bash < 3.2 you might want to use the hack/patch that I posted to the mc-devel list in relation to this report. That patch is almost identical to this one, but by escaping numbers as well it remains compatible with bash > 2.05b. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 13 02:14:51 2006 From: INVALID.NOREPLY at gnu.org (Mehmet Kemal EROL) Date: Mon, 13 Nov 2006 02:14:51 +0000 Subject: [bug #18136] MC wont work with new bash-3.2 propeply with all directories. In-Reply-To: <20061112-175426.sv26390.46745@savannah.gnu.org> References: <20061028-122212.sv20252.99093@savannah.gnu.org> <20061103-052104.sv53977.52633@savannah.gnu.org> <20061112-161831.sv54310.97804@savannah.gnu.org> <20061112-175426.sv26390.46745@savannah.gnu.org> Message-ID: <20061113-041451.sv54310.47649@savannah.gnu.org> Follow-up Comment #4, bug #18136 (project mc): Thank you very much for your kind reply, dear Leonard! I found the hack you have mentioned, made an appropriate patch for our Gentoo ebuild system, run the new installation with success and no ill side-effects. You might want to follow our exchange at: http://bugs.gentoo.org/show_bug.cgi?id=153925 Thank you again for your friendly help! _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ache666 at gmail.com Mon Nov 13 14:33:14 2006 From: ache666 at gmail.com (Andrey Chernov) Date: Mon, 13 Nov 2006 17:33:14 +0300 Subject: Some MC 4.6.1 bugs Message-ID: <1475075654.20061113173314@gmail.com> Hello mc-devel, 1) When compiled with Slang MC can't input Russian (8bit) letters and can't draw proper pseudographics lines with xterm (qqqqqq etc shown). Other pseudographics terminal I try (putty) display them normally. Note: Russian character are entered normally and pseudographics is fine with xterm when compiled with ncureses. 2) When compiled with ncurses, MC highlights all Russian (8bit) characters in internal viewer. It is because ncurses attributes extension happens converting signed negative char with 8bit On to int. You need to use (unsigned char) cast before printing characters in ncurses mode. Note: Russian characters are not highlighted when compiled with Slang. I use "Full 8-bit input" On and KOI8-R as Input/display codepage in both cases. -- Best regards, Andrey Chernov From gtrenin at gmail.com Mon Nov 20 14:34:50 2006 From: gtrenin at gmail.com (Grigory Trenin) Date: Mon, 20 Nov 2006 17:34:50 +0300 Subject: [PATCH] man2hlp breaks links in help file Message-ID: <4561BD0A.9000603@gmail.com> Hi all, src/man2hlp.c utility sometimes replaces spaces in the link target with newlines. There is a workaround code in src/help.c:141, which handles that case. But it doesn't always help. If the link is used inside the indented block (made by .TP tag), man2hlp will insert additional spaces inside the link. For example, the link "Directory tree" will become "Directory\n Tree". This will result to a broken link. Currently, in Russian help file there are two such broken links (one in "Listing Mode..." section, and the other one in "Options/Virtual FS" section). The result of trying to follow such broken link is displayed at this screenshot: http://img227.imageshack.us/img227/179/mcbrokenlinkmo3.png It is lucky that there are no such broken links in English help, but they can appear in the future. So I made a patch for the man2hlp utility, to make man2hlp never insert newline and spaces inside the link target. Only the link target (the invisible part of the link) is affected by the patch. The link name itself (that is visible in the Help Viewer) can always be wrapped to another line, and it never causes problems. Regards, Grigory Trenin. -- Grigory Trenin * src/man2hlp.c (print_string): Don't insert spaces or newlines in link target. --- src/man2hlp.c.orig 2005-10-12 01:56:49.000000000 +0400 +++ src/man2hlp.c 2006-11-20 15:34:05.000000000 +0300 @@ -252,8 +252,11 @@ if (*(buffer)) { len = string_len (buffer); /* Change the line if about to break the right margin */ - if (col + len >= HELP_TEXT_WIDTH) - newline (); + /* But avoid inserting newlines and spaces inside the link */ + if (len && (strchr(buffer, CHAR_LINK_POINTER) != NULL || + strchr(buffer, CHAR_LINK_END) == NULL)) + if (col + len >= HELP_TEXT_WIDTH) + newline (); /* Words are separated by spaces */ if (col > 0) { fputc (' ', f_out); From ptsekov at gmx.net Tue Nov 21 14:02:47 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 21 Nov 2006 16:02:47 +0200 (EET) Subject: [PATCH] man2hlp breaks links in help file In-Reply-To: <4561BD0A.9000603@gmail.com> References: <4561BD0A.9000603@gmail.com> Message-ID: Hello Grogory, On Mon, 20 Nov 2006, Grigory Trenin wrote: > src/man2hlp.c utility sometimes replaces spaces in the link target with > newlines. > There is a workaround code in src/help.c:141, which handles that case. > > But it doesn't always help. If the link is used inside the indented > block (made by .TP tag), man2hlp will insert additional spaces inside the > link. > For example, the link "Directory tree" will become "Directory\n Tree". > This will result to a broken link. I understand what's wrong but I'll need your help before checking your patch. Since you already looked at that code I'll ask you first before looking at the code myself - isn't it better to rip the link wrapping code out of man2hlp.c and move it in the help viewer ? I think this would be better fix in the long term. Thanks! From gtrenin at gmail.com Tue Nov 21 19:51:31 2006 From: gtrenin at gmail.com (Grigory Trenin) Date: Tue, 21 Nov 2006 22:51:31 +0300 Subject: [PATCH] man2hlp breaks links in help file In-Reply-To: References: <4561BD0A.9000603@gmail.com> Message-ID: <456358C3.2090508@gmail.com> Hello Pavel, Pavel Tsekov wrote: > isn't it better to rip the link wrapping code out of > man2hlp.c and move it in the help viewer ? I think this > would be better fix in the long term. I think that doing all line wrapping in the Help Viewer "on the fly" will require more changes (like defining a new control character to mark indented text), though it may be better in long term. This is a larger amount of work, compared to my tiny patch :) Another possible way is to add to the Help Viewer a code that will squeeze several spaces to one space ("Directory Tree" --> "Directory Tree"). But I think that it is better not to produce such broken links at all (i.e. to fix man2hlp.c) instead of producing them and then fixing in the Help Viewer. Regards, Grigory. From ptsekov at gmx.net Tue Nov 21 20:39:28 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 21 Nov 2006 22:39:28 +0200 (EET) Subject: [PATCH] man2hlp breaks links in help file In-Reply-To: <456358C3.2090508@gmail.com> References: <4561BD0A.9000603@gmail.com> <456358C3.2090508@gmail.com> Message-ID: On Tue, 21 Nov 2006, Grigory Trenin wrote: > Pavel Tsekov wrote: > >> isn't it better to rip the link wrapping code out of >> man2hlp.c and move it in the help viewer ? I think this >> would be better fix in the long term. > > > I think that doing all line wrapping in the Help Viewer "on the fly" > will require more changes (like defining a new control character to > mark indented text), though it may be better in long term. > This is a larger amount of work, compared to my tiny patch :) > > Another possible way is to add to the Help Viewer a code that will > squeeze several spaces to one space > ("Directory Tree" --> "Directory Tree"). > But I think that it is better not to produce such broken > links at all (i.e. to fix man2hlp.c) instead of > producing them and then fixing in the Help Viewer. Sure - man2hlp.c shouldn't try to mess with the link target. That's why I suggest that we move the link wrapping code to the help viewer. After all it is up to the link viewer to interpret the help file and display it as it sees fit - it knows what it has to do best. Give me a few days to look at the code to try to estimate how hard is it to implement the wrapping in the viewer. From INVALID.NOREPLY at gnu.org Sun Nov 26 23:08:45 2006 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Sun, 26 Nov 2006 23:08:45 +0000 Subject: [patch #1042] hotkeys and other improvements in hotlist In-Reply-To: <20060203-011231.sv36205.9122@savannah.gnu.org> References: <20060131-174935.sv36205.99633@savannah.gnu.org> <20060131-191610.sv14787.8291@savannah.gnu.org> <20060201-002823.sv36205.5020@savannah.gnu.org> <20060202-164459.sv36205.32467@savannah.gnu.org> <20060202-175535.sv14787.65282@savannah.gnu.org> <20060203-011231.sv36205.9122@savannah.gnu.org> Message-ID: <20061126-230845.sv0.36958@savannah.gnu.org> Follow-up Comment #16, patch #1042 (project mc): 9ff133668c59080aa7ceda23978f7a60 lavoro-ariccia http://6.invocando.com/buffy-sito-italiano/ rex-lavatrici-da-incasso inurl-gb-sign-hi http://20.troverete.com/samsung-dtb-9500f/ analisi-laboratorio midi-pino-daniele http://9.desolazioni.com/amanda-lear-nuda/ alessia-ventura-velo addobbi http://14.invocando.com/ferrovia-dello-stato-orario-ufficiale-trenitalia/ ragazza-calangianus corriere-della-sera-magazine http://16.risuscita.com/missili/ campeggio-fornello celle-di-lievitazione http://14.troverete.com/lombardi-satriani/ tradizione-costume-spagna abbagliamento http://13.desolazioni.com/messa-opera-tetto/ mappa-forio pedretti-granito http://4.troverete.com/auto-occasione-veneto/ mature-viziose 1d45129e484a67f82521dd1274690b40 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From jnovy at redhat.com Mon Nov 27 12:26:15 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 27 Nov 2006 13:26:15 +0100 Subject: [PATCH] mc crashes when temporary directory cannot be created Message-ID: <1164630375.2362.14.camel@redhat.usu> Hi all, there is a breakage in util.c and utilunix.c related to temporary files creation. The problem is that if a directory for temporary files cannot be created mc ends up in infinite loop caused by: tmpbase = concat_dir_and_file (mc_tmpdir (), prefix); in mc_mkstemps() which then calls mc_tmpdir() back infinitely and ends up in a stack underflow. The attached patch fixes it as it disables the creation of the temporary files when the temp. directory couldn't be created. Cheers, Jindrich -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-tmpcrash.patch Type: text/x-patch Size: 650 bytes Desc: not available URL: From ptsekov at gmx.net Mon Nov 27 15:37:06 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 27 Nov 2006 17:37:06 +0200 (EET) Subject: [PATCH] mc crashes when temporary directory cannot be created In-Reply-To: <1164630375.2362.14.camel@redhat.usu> References: <1164630375.2362.14.camel@redhat.usu> Message-ID: Hello Jindrich, On Mon, 27 Nov 2006, Jindrich Novy wrote: > there is a breakage in util.c and utilunix.c related to temporary files > creation. The problem is that if a directory for temporary files cannot > be created mc ends up in infinite loop caused by: > > tmpbase = concat_dir_and_file (mc_tmpdir (), prefix); > > in mc_mkstemps() which then calls mc_tmpdir() back infinitely and ends > up in a stack underflow. > > The attached patch fixes it as it disables the creation of the temporary > files when the temp. directory couldn't be created. Ok. But... what happens if any of the following error conditions occur ? if (lstat (buffer, &st) == 0) { /* Sanity check for existing directory */ if (!S_ISDIR (st.st_mode)) error = _("%s is not a directory\n"); else if (st.st_uid != getuid ()) error = _("Directory %s is not owned by you\n"); else if (((st.st_mode & 0777) != 0700) && (chmod (buffer, 0700) != 0)) error = _("Cannot set correct permissions for directory %s\n"); } else { Wouldn't it cause the same loop as when mkdir() fails ? From jnovy at redhat.com Tue Nov 28 12:21:56 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 28 Nov 2006 13:21:56 +0100 Subject: [PATCH] mc crashes when temporary directory cannot be created In-Reply-To: References: <1164630375.2362.14.camel@redhat.usu> Message-ID: <1164716516.2434.18.camel@redhat.usu> Hi Pavel, On Mon, 2006-11-27 at 17:37 +0200, Pavel Tsekov wrote: > Hello Jindrich, > > On Mon, 27 Nov 2006, Jindrich Novy wrote: > > > there is a breakage in util.c and utilunix.c related to temporary files > > creation. The problem is that if a directory for temporary files cannot > > be created mc ends up in infinite loop caused by: > > > > tmpbase = concat_dir_and_file (mc_tmpdir (), prefix); > > > > in mc_mkstemps() which then calls mc_tmpdir() back infinitely and ends > > up in a stack underflow. > > > > The attached patch fixes it as it disables the creation of the temporary > > files when the temp. directory couldn't be created. > > Ok. But... what happens if any of the following > error conditions occur ? > > if (lstat (buffer, &st) == 0) { > /* Sanity check for existing directory */ > if (!S_ISDIR (st.st_mode)) > error = _("%s is not a directory\n"); > else if (st.st_uid != getuid ()) > error = _("Directory %s is not owned by you\n"); > else if (((st.st_mode & 0777) != 0700) > && (chmod (buffer, 0700) != 0)) > error = _("Cannot set correct permissions for directory > %s\n"); > } else { > > Wouldn't it cause the same loop as when mkdir() fails ? Good point, I missed that. IMO only removal of the fallback will prevent the infinite loop in any case as it shouldn't call mc_mkstemps() at all. I'm sending patch for it. Thoughts? Jindrich -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-tmpcrash.patch Type: text/x-patch Size: 1067 bytes Desc: not available URL: From gtrenin at gmail.com Wed Nov 29 18:59:56 2006 From: gtrenin at gmail.com (Grigory Trenin) Date: Wed, 29 Nov 2006 21:59:56 +0300 Subject: [PATCH] Help Viewer - incorrect behaviour of arrrow key Message-ID: <456DD8AC.2080806@gmail.com> Hello all, While browsing MC's help, I've noticed a strange behaviour of arrow key. After I visit some topic and return back (using arrow key), the behaviour of arrow key weirdly changes: instead of selecting the previous link, it jumps to the top of the window! Here is a detailed description how to reproduce it: 1) Open the Help Contents (press , , ) 2) Navigate some lines forward (press or several times) 3) Enter the selected topic (press ) 4) Return back (press ) 5) Move to the top of Contents (press ) 6) Now try navigating the Contents using the and arrow keys. (for example, press for 5 times, then press ). You will notice that when you press key the selection jumps to the top of window. The problem is in the help_handle_key() function: case KEY_UP: case ALT ('\t'): /* select previous link */ new_item = select_prev_link (startpoint, selected_item); The 'startpoint' variable should be a pointer to the first byte displayed in the Help window. But here it has a wrong value - that's the problem. That's why select_prev_link() cannot find the link and returns NULL, and the selection moves to the first link in the window. I tried to find out what's wrong with the 'startpoint' variable. I came to the conclusion that 'startpoint' is used here erroneously instead of 'currentpoint' variable. 'currentpoint' always contains a pointer to the first byte displayed, and it should be used here. And by the way, 'startpoint' variable seems to be totally useless. So in my patch I replaced 'startpoint' with 'currentpoint' and removed the 'startpoint' variable completely. Regards, Grigory Trenin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: help.patch URL: From leonard at den.ottolander.nl Wed Nov 29 19:59:28 2006 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 29 Nov 2006 20:59:28 +0100 Subject: [PATCH] mc crashes when temporary directory cannot be created In-Reply-To: <1164716516.2434.18.camel@redhat.usu> References: <1164630375.2362.14.camel@redhat.usu> <1164716516.2434.18.camel@redhat.usu> Message-ID: <1164830368.2825.6.camel@athlon> Hello Jindrich, On Tue, 2006-11-28 at 13:21 +0100, Jindrich Novy wrote: > IMO only removal of the fallback will prevent > the infinite loop in any case as it shouldn't call mc_mkstemps() at all. That cure seems worse than the disease. Isn't the real problem the fact that mc_mkstemps() blindly concats tmpdir to the prefix instead of testing if mc_tmpdir() succeeded? Why not abort mc_mkstemps() if mc_tmpdir() returns "/dev/null/"? What about the attached (untested) patch? By the way, could you please add the -p option to your diffs? Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: util.c.diff Type: text/x-patch Size: 730 bytes Desc: not available URL: From gtrenin at gmail.com Wed Nov 29 21:11:41 2006 From: gtrenin at gmail.com (Grigory Trenin) Date: Thu, 30 Nov 2006 00:11:41 +0300 Subject: [PATCH] Help Viewer - incorrect behaviour of arrrow key In-Reply-To: <456DD8AC.2080806@gmail.com> References: <456DD8AC.2080806@gmail.com> Message-ID: <456DF78D.6090707@gmail.com> s/right arrow/left arrow/g Of course I meant key when I was talking about going back to the previous topic. Sorry for that. -- Grigory. From jnovy at redhat.com Thu Nov 30 09:03:21 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 30 Nov 2006 10:03:21 +0100 Subject: [PATCH] mc crashes when temporary directory cannot be created In-Reply-To: <1164830368.2825.6.camel@athlon> References: <1164630375.2362.14.camel@redhat.usu> <1164716516.2434.18.camel@redhat.usu> <1164830368.2825.6.camel@athlon> Message-ID: <1164877401.2402.22.camel@redhat.usu> Hi Leonard, On Wed, 2006-11-29 at 20:59 +0100, Leonard den Ottolander wrote: > Hello Jindrich, > > On Tue, 2006-11-28 at 13:21 +0100, Jindrich Novy wrote: > > IMO only removal of the fallback will prevent > > the infinite loop in any case as it shouldn't call mc_mkstemps() at all. > > That cure seems worse than the disease. Isn't the real problem the fact > that mc_mkstemps() blindly concats tmpdir to the prefix instead of > testing if mc_tmpdir() succeeded? Why not abort mc_mkstemps() if > mc_tmpdir() returns "/dev/null/"? I'm not quite sure I got the point. We may want to prevent infinite loops caused by the subsequent function calls, such design is dangerous by design. The fallback will never work without adding hacks to mc_mktemps()/mc_tmpdir() to check for special arguments what doesn't look too nice to me. Considering that insufficient space in TMPDIR is very rare, I would vote for removing the dangerous fallback completely what is done in the previous patch. mc works fine after that even without the fallback. > What about the attached (untested) patch? $ TMPDIR=/dev/null mc Cannot create temporary directory /dev/null/mc-jnovy: Not a directory (20) Cannot create temporary directory /dev/null/mc-jnovy: Not a directory (20) Cannot create temporary directory /dev/null/mc-jnovy: Not a directory (20) Cannot create temporary directory /dev/null/mc-jnovy: Not a directory (20) Segmentation fault > By the way, could you please add the -p option to your diffs? Sure. Jindrich From ptsekov at gmx.net Thu Nov 30 18:01:09 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 30 Nov 2006 20:01:09 +0200 (EET) Subject: [PATCH] Help Viewer - incorrect behaviour of arrrow key In-Reply-To: <456DD8AC.2080806@gmail.com> References: <456DD8AC.2080806@gmail.com> Message-ID: Hello Grigory, On Wed, 29 Nov 2006, Grigory Trenin wrote: > Here is a detailed description how to reproduce it: > > 1) Open the Help Contents (press , , ) > 2) Navigate some lines forward (press or several times) > 3) Enter the selected topic (press ) > 4) Return back (press ) > 5) Move to the top of Contents (press ) > 6) Now try navigating the Contents using the and arrow keys. > (for example, press for 5 times, then press ). > You will notice that when you press key the selection > jumps to the top of window. I can confirm the problem. > The problem is in the help_handle_key() function: > case KEY_UP: > case ALT ('\t'): > /* select previous link */ > new_item = select_prev_link (startpoint, selected_item); > > The 'startpoint' variable should be a pointer to the first byte > displayed in the Help window. But here it has a wrong value - that's > the problem. That's why select_prev_link() cannot find the link and > returns NULL, and the selection moves to the first link in the window. > > I tried to find out what's wrong with the 'startpoint' variable. > I came to the conclusion that 'startpoint' is used here erroneously > instead of 'currentpoint' variable. I am not convinced of that yet - see below. It's more likely that the navigation code messes the value of 'startpoint'. > 'currentpoint' always contains a pointer to the first byte displayed, > and it should be used here. And by the way, 'startpoint' variable > seems to be totally useless. This is not true - 'currentpoint' points to the first byte of the currently disaplyed help contents, while 'startpoint' points to the start of the current link/topic. 'startpoint' gets messed after one returns back from following a link. > So in my patch I replaced 'startpoint' with 'currentpoint' and > removed the 'startpoint' variable completely. I won't apply this patch yet. I want to investigate further. From ptsekov at gmx.net Thu Nov 30 18:04:46 2006 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 30 Nov 2006 20:04:46 +0200 (EET) Subject: [PATCH] mc crashes when temporary directory cannot be created In-Reply-To: <1164830368.2825.6.camel@athlon> References: <1164630375.2362.14.camel@redhat.usu> <1164716516.2434.18.camel@redhat.usu> <1164830368.2825.6.camel@athlon> Message-ID: On Wed, 29 Nov 2006, Leonard den Ottolander wrote: > Hello Jindrich, > > On Tue, 2006-11-28 at 13:21 +0100, Jindrich Novy wrote: >> IMO only removal of the fallback will prevent >> the infinite loop in any case as it shouldn't call mc_mkstemps() at all. > > That cure seems worse than the disease. Isn't the real problem the fact > that mc_mkstemps() blindly concats tmpdir to the prefix instead of > testing if mc_tmpdir() succeeded? Why not abort mc_mkstemps() if > mc_tmpdir() returns "/dev/null/"? > > What about the attached (untested) patch? > > By the way, could you please add the -p option to your diffs? There is an even simpler cure. In mc_tmpdir() when executing the fallback code pass an absolute path to mc_mkstemps(). This will prevent the loop. However I am not yet conviced that this is the best solution. I am still investigating.